Mixing
How to deal with incompetent lead?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
6
down vote
favorite
Alright, so we are a two people team directly reporting to our director. I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead. We both are Programmers and we interact with our customers directly.
Now, I do not appreciate his coding style at all. In my opinion his code is 'Quick and Dirty'. Now, this can be purely my opinion and may have nothing to do with the facts. However, I try to stay away from the projects that he works on so that I don't have to defend something I dont agree with.
So far it has been working out for me. However, last week his project blew up and for some reason he pretended to be busy and I had to fix the code.
Now, since my director has to approve any immediate code changes in production. He had a chance to look at it and he was pretty dissatisfied with the fact that there are problems in the production and also that quality of the code was really not so good.
Now, again I do not want to start pointing fingers BUT at the same time, I do not want to defend something I do not agree with. I had no idea what to say when the code and system were criticized badly.
- I do not want to be a bad team player and play a blame game
- Also, I do not want my boss to think I had any part in writing such a low quality code.
How do I convey that message?
colleagues politics teamwork intervention software-development
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
asked Feb 5 '16 at 18:32
WorkBee
1504
 |Â
show 3 more comments
up vote
6
down vote
favorite
Alright, so we are a two people team directly reporting to our director. I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead. We both are Programmers and we interact with our customers directly.
Now, I do not appreciate his coding style at all. In my opinion his code is 'Quick and Dirty'. Now, this can be purely my opinion and may have nothing to do with the facts. However, I try to stay away from the projects that he works on so that I don't have to defend something I dont agree with.
So far it has been working out for me. However, last week his project blew up and for some reason he pretended to be busy and I had to fix the code.
Now, since my director has to approve any immediate code changes in production. He had a chance to look at it and he was pretty dissatisfied with the fact that there are problems in the production and also that quality of the code was really not so good.
Now, again I do not want to start pointing fingers BUT at the same time, I do not want to defend something I do not agree with. I had no idea what to say when the code and system were criticized badly.
- I do not want to be a bad team player and play a blame game
- Also, I do not want my boss to think I had any part in writing such a low quality code.
How do I convey that message?
colleagues politics teamwork intervention software-development
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
asked Feb 5 '16 at 18:32
WorkBee
1504
3
If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team.
– Joel Etherton
Feb 5 '16 at 20:00
5
As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction.
– Joel Etherton
Feb 5 '16 at 20:03
1
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.
– Jim G.
Feb 5 '16 at 21:05
3
If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards?
– Carson63000
Feb 5 '16 at 21:48
1
@JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
– Lilienthal♦
Feb 8 '16 at 12:54
 |Â
show 3 more comments
up vote
6
down vote
favorite
up vote
6
down vote
favorite
Alright, so we are a two people team directly reporting to our director. I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead. We both are Programmers and we interact with our customers directly.
Now, I do not appreciate his coding style at all. In my opinion his code is 'Quick and Dirty'. Now, this can be purely my opinion and may have nothing to do with the facts. However, I try to stay away from the projects that he works on so that I don't have to defend something I dont agree with.
So far it has been working out for me. However, last week his project blew up and for some reason he pretended to be busy and I had to fix the code.
Now, since my director has to approve any immediate code changes in production. He had a chance to look at it and he was pretty dissatisfied with the fact that there are problems in the production and also that quality of the code was really not so good.
Now, again I do not want to start pointing fingers BUT at the same time, I do not want to defend something I do not agree with. I had no idea what to say when the code and system were criticized badly.
- I do not want to be a bad team player and play a blame game
- Also, I do not want my boss to think I had any part in writing such a low quality code.
How do I convey that message?
colleagues politics teamwork intervention software-development
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
asked Feb 5 '16 at 18:32
WorkBee
1504
Alright, so we are a two people team directly reporting to our director. I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead. We both are Programmers and we interact with our customers directly.
Now, I do not appreciate his coding style at all. In my opinion his code is 'Quick and Dirty'. Now, this can be purely my opinion and may have nothing to do with the facts. However, I try to stay away from the projects that he works on so that I don't have to defend something I dont agree with.
So far it has been working out for me. However, last week his project blew up and for some reason he pretended to be busy and I had to fix the code.
Now, since my director has to approve any immediate code changes in production. He had a chance to look at it and he was pretty dissatisfied with the fact that there are problems in the production and also that quality of the code was really not so good.
Now, again I do not want to start pointing fingers BUT at the same time, I do not want to defend something I do not agree with. I had no idea what to say when the code and system were criticized badly.
- I do not want to be a bad team player and play a blame game
- Also, I do not want my boss to think I had any part in writing such a low quality code.
How do I convey that message?
colleagues politics teamwork intervention software-development
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
asked Feb 5 '16 at 18:32
WorkBee
1504
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
edited Feb 14 '16 at 14:42
Jim G.
11.8k105373
11.8k105373
asked Feb 5 '16 at 18:32
WorkBee
1504
asked Feb 5 '16 at 18:32
WorkBee
1504
asked Feb 5 '16 at 18:32
WorkBee
1504
1504
3
If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team.
– Joel Etherton
Feb 5 '16 at 20:00
5
As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction.
– Joel Etherton
Feb 5 '16 at 20:03
1
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.
– Jim G.
Feb 5 '16 at 21:05
3
If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards?
– Carson63000
Feb 5 '16 at 21:48
1
@JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
– Lilienthal♦
Feb 8 '16 at 12:54
 |Â
show 3 more comments
3
If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team.
– Joel Etherton
Feb 5 '16 at 20:00
5
As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction.
– Joel Etherton
Feb 5 '16 at 20:03
1
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.
– Jim G.
Feb 5 '16 at 21:05
3
If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards?
– Carson63000
Feb 5 '16 at 21:48
1
@JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
– Lilienthal♦
Feb 8 '16 at 12:54
3
3
If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team.
– Joel Etherton
Feb 5 '16 at 20:00
If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team.
– Joel Etherton
Feb 5 '16 at 20:00
5
5
As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction.
– Joel Etherton
Feb 5 '16 at 20:03
As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction.
– Joel Etherton
Feb 5 '16 at 20:03
1
1
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.– Jim G.
Feb 5 '16 at 21:05
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.– Jim G.
Feb 5 '16 at 21:05
3
3
If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards?
– Carson63000
Feb 5 '16 at 21:48
If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards?
– Carson63000
Feb 5 '16 at 21:48
1
1
@JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
– Lilienthal♦
Feb 8 '16 at 12:54
@JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
– Lilienthal♦
Feb 8 '16 at 12:54
 |Â
show 3 more comments
5 Answers
5
active
oldest
votes
up vote
12
down vote
accepted
Stop working in silos.
The more you have a culture of "stay on your half of the codebase", the more likely it is that:
- code will go wrong because nobody asks questions
- it will take you a long time to find and understand code when things do go wrong
- you cannot explain why design decisions have been made
- you end up breaking something else when you 'fix' the code you've never seen before
- you end up looking like you don't understand it.
As you've just found this leaves you playing the blame game whether you want to or not: ultimately, your answer is going to boil down to "I don't know, that's not my code".
Right now, you can try to be slightly more diplomatic:
I'm afraid I'm not familiar with this part of the code base.
That's not really my style, but perhaps (Team Lead) had a reason for coding it that way.
You're right not to jump in and criticise. If you have different styles it's entirely possible there are advantages to the way the code is written that you just don't see. Even if not, your director has presumably approved this code before and perhaps hired your lead. Instead offer different ways of doing things: "I would have combined these into one method", etc. There's no 'good' answer in this situation, but focus on the practicalities of getting the bug fixed and the release tested and deployed.
... but that won't work next time.
You've still got a bunch of 'problem code' that you've ignored up till now, but can't afford to keep ignoring. Your team lead might not be fussed about code quality but when his code next falls over, you'll be asked why you weren't addressing the problem.
- Do code reviews.
- Try to document each other's code, explaining edge cases, etc.
- Make sure all your code is tested. Run code coverage for your tests.
- Divide tasks so that one of you writes tests and the other produces code which meets the tests. Swap roles.
- When new development comes up, ask to be assigned to tasks which force you to work with code you've not used before.
Even if you don't end up exposing yourself to all the darkest reaches of your colleagues codebase, you'll at least begin to notice enough patterns in the things your colleague does which might help you diagnose bugs faster next time.
answered Feb 5 '16 at 20:08
user52889
7,21531527
2
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
suggest improvements |Â
up vote
4
down vote
Honest, direct communication is fine. Bring solutions, not problems. You can raise the following points with your boss:
- You noticed the problem with the production code was preventable.
- Your fix patched the problem over--but doesn't create stable, maintainable code.
- Recommend code reviews to avoid future problems.
Code reviews are magical places where junior developers can introduce new techniques and best practices into production, without ruffling feathers. The focus is on the code, not the person. Don't condescend, over-instruct, or generalize beyond the current example. Simply state that for this particular case, there is a useful pattern you've had success with. Be specific about a single issue that can arise for each change. "If we change this to that, it will leak memory. If we change this to that, it will fail gracefully for poor inputs, such as this, which has occurred before." In contentious situations like this, you "rotate the code"--everyone reviews the code, but the person to your left in the meeting makes the changes (or next tallest, or next birthday, etc.). Everyone benefits, and no one loses face at the time--although people who require the most changes become obvious over time.
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
Simple state that for this particular case, there is a useful pattern you've had success with.- The name for this is teaching.
– Joel Etherton
Feb 5 '16 at 20:01
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
1
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
suggest improvements |Â
up vote
2
down vote
Fix the problem
You can either continue the same "style" of coding and get the immediate problems fixed or take the time to fix the over-all problems plaguing this code set. Your boss will have to decide. That's why he gets the big bucks.
Hopefully, there will be some sort of postmortem on this problem and your team needs to decide if you're going to allow the other developer continue with the quick and dirty programming.
Again, your boss is going to have to decide how to move forward. I don't know why your boss doesn't enforce what appears to be a higher standard for coding on the sr programmer. The technical debt ultimately had to be paid by everyone.
All you can do is make suggestions and do your best given the constraints of your boss's decisions.
suggest improvements |Â
up vote
1
down vote
If you work as a team you are Both responsable for the quality of the code (even if you did not write it). All code should be code reviewed and a consensus reached.
If you have trouble reaching consensus then install automated tools to do the validation only allow commits that pass the automated validation.
As how to handle your current situation.
- Say this code was not your project.
- You only fixed the specific bug (not the whole project/file) to prevent instability.
- Suggest how the processes can be improved overall.
answered Feb 5 '16 at 19:30
Martin York
953616
suggest improvements |Â
up vote
1
down vote
- Meet with your director and explain your constructive disagreement with your team lead's coding style. Use tact.
- Come prepared with about 3 coding, architecture, or process examples that support your point of view.
- Depending upon the nature of the situation, and the personality of the team lead, you may want to include the team lead in this meeting.
- Explain your point of view, but do not argue with your director. Listen to his/her opinion. Be prepared to conclude the meeting in less than an hour.
- Leave the meeting. Finish your day. Go home. Have dinner. Go to sleep.
- During your commute to work on the next business day, evaluate your meeting with your director. Was he/she fair?
- If 'Yes' (even if he/she did not agree with your point of view), then be prepared to adjust your way of doing things (other people have responded with some great advice).
- If 'No', or if you feel that you cannot coexist with this team lead, then you have two options: 1. Ask your director if you can transfer to another department. 2. Start looking for a new job.
More on the 'Start looking for a new job' advice:
- Pursue this option only as a last resort.
- In the workplace (and in life in general), try your best to see the other person's point of view.
- But ultimately, if you're unable to make things work, you should start looking for a new job. Life is just too short and coding jobs are plentiful.
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
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();
);
);
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
accepted
Stop working in silos.
The more you have a culture of "stay on your half of the codebase", the more likely it is that:
- code will go wrong because nobody asks questions
- it will take you a long time to find and understand code when things do go wrong
- you cannot explain why design decisions have been made
- you end up breaking something else when you 'fix' the code you've never seen before
- you end up looking like you don't understand it.
As you've just found this leaves you playing the blame game whether you want to or not: ultimately, your answer is going to boil down to "I don't know, that's not my code".
Right now, you can try to be slightly more diplomatic:
I'm afraid I'm not familiar with this part of the code base.
That's not really my style, but perhaps (Team Lead) had a reason for coding it that way.
You're right not to jump in and criticise. If you have different styles it's entirely possible there are advantages to the way the code is written that you just don't see. Even if not, your director has presumably approved this code before and perhaps hired your lead. Instead offer different ways of doing things: "I would have combined these into one method", etc. There's no 'good' answer in this situation, but focus on the practicalities of getting the bug fixed and the release tested and deployed.
... but that won't work next time.
You've still got a bunch of 'problem code' that you've ignored up till now, but can't afford to keep ignoring. Your team lead might not be fussed about code quality but when his code next falls over, you'll be asked why you weren't addressing the problem.
- Do code reviews.
- Try to document each other's code, explaining edge cases, etc.
- Make sure all your code is tested. Run code coverage for your tests.
- Divide tasks so that one of you writes tests and the other produces code which meets the tests. Swap roles.
- When new development comes up, ask to be assigned to tasks which force you to work with code you've not used before.
Even if you don't end up exposing yourself to all the darkest reaches of your colleagues codebase, you'll at least begin to notice enough patterns in the things your colleague does which might help you diagnose bugs faster next time.
answered Feb 5 '16 at 20:08
user52889
7,21531527
2
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
suggest improvements |Â
up vote
12
down vote
accepted
Stop working in silos.
The more you have a culture of "stay on your half of the codebase", the more likely it is that:
- code will go wrong because nobody asks questions
- it will take you a long time to find and understand code when things do go wrong
- you cannot explain why design decisions have been made
- you end up breaking something else when you 'fix' the code you've never seen before
- you end up looking like you don't understand it.
As you've just found this leaves you playing the blame game whether you want to or not: ultimately, your answer is going to boil down to "I don't know, that's not my code".
Right now, you can try to be slightly more diplomatic:
I'm afraid I'm not familiar with this part of the code base.
That's not really my style, but perhaps (Team Lead) had a reason for coding it that way.
You're right not to jump in and criticise. If you have different styles it's entirely possible there are advantages to the way the code is written that you just don't see. Even if not, your director has presumably approved this code before and perhaps hired your lead. Instead offer different ways of doing things: "I would have combined these into one method", etc. There's no 'good' answer in this situation, but focus on the practicalities of getting the bug fixed and the release tested and deployed.
... but that won't work next time.
You've still got a bunch of 'problem code' that you've ignored up till now, but can't afford to keep ignoring. Your team lead might not be fussed about code quality but when his code next falls over, you'll be asked why you weren't addressing the problem.
- Do code reviews.
- Try to document each other's code, explaining edge cases, etc.
- Make sure all your code is tested. Run code coverage for your tests.
- Divide tasks so that one of you writes tests and the other produces code which meets the tests. Swap roles.
- When new development comes up, ask to be assigned to tasks which force you to work with code you've not used before.
Even if you don't end up exposing yourself to all the darkest reaches of your colleagues codebase, you'll at least begin to notice enough patterns in the things your colleague does which might help you diagnose bugs faster next time.
answered Feb 5 '16 at 20:08
user52889
7,21531527
2
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
suggest improvements |Â
up vote
12
down vote
accepted
up vote
12
down vote
accepted
Stop working in silos.
The more you have a culture of "stay on your half of the codebase", the more likely it is that:
- code will go wrong because nobody asks questions
- it will take you a long time to find and understand code when things do go wrong
- you cannot explain why design decisions have been made
- you end up breaking something else when you 'fix' the code you've never seen before
- you end up looking like you don't understand it.
As you've just found this leaves you playing the blame game whether you want to or not: ultimately, your answer is going to boil down to "I don't know, that's not my code".
Right now, you can try to be slightly more diplomatic:
I'm afraid I'm not familiar with this part of the code base.
That's not really my style, but perhaps (Team Lead) had a reason for coding it that way.
You're right not to jump in and criticise. If you have different styles it's entirely possible there are advantages to the way the code is written that you just don't see. Even if not, your director has presumably approved this code before and perhaps hired your lead. Instead offer different ways of doing things: "I would have combined these into one method", etc. There's no 'good' answer in this situation, but focus on the practicalities of getting the bug fixed and the release tested and deployed.
... but that won't work next time.
You've still got a bunch of 'problem code' that you've ignored up till now, but can't afford to keep ignoring. Your team lead might not be fussed about code quality but when his code next falls over, you'll be asked why you weren't addressing the problem.
- Do code reviews.
- Try to document each other's code, explaining edge cases, etc.
- Make sure all your code is tested. Run code coverage for your tests.
- Divide tasks so that one of you writes tests and the other produces code which meets the tests. Swap roles.
- When new development comes up, ask to be assigned to tasks which force you to work with code you've not used before.
Even if you don't end up exposing yourself to all the darkest reaches of your colleagues codebase, you'll at least begin to notice enough patterns in the things your colleague does which might help you diagnose bugs faster next time.
answered Feb 5 '16 at 20:08
user52889
7,21531527
Stop working in silos.
The more you have a culture of "stay on your half of the codebase", the more likely it is that:
- code will go wrong because nobody asks questions
- it will take you a long time to find and understand code when things do go wrong
- you cannot explain why design decisions have been made
- you end up breaking something else when you 'fix' the code you've never seen before
- you end up looking like you don't understand it.
As you've just found this leaves you playing the blame game whether you want to or not: ultimately, your answer is going to boil down to "I don't know, that's not my code".
Right now, you can try to be slightly more diplomatic:
I'm afraid I'm not familiar with this part of the code base.
That's not really my style, but perhaps (Team Lead) had a reason for coding it that way.
You're right not to jump in and criticise. If you have different styles it's entirely possible there are advantages to the way the code is written that you just don't see. Even if not, your director has presumably approved this code before and perhaps hired your lead. Instead offer different ways of doing things: "I would have combined these into one method", etc. There's no 'good' answer in this situation, but focus on the practicalities of getting the bug fixed and the release tested and deployed.
... but that won't work next time.
You've still got a bunch of 'problem code' that you've ignored up till now, but can't afford to keep ignoring. Your team lead might not be fussed about code quality but when his code next falls over, you'll be asked why you weren't addressing the problem.
- Do code reviews.
- Try to document each other's code, explaining edge cases, etc.
- Make sure all your code is tested. Run code coverage for your tests.
- Divide tasks so that one of you writes tests and the other produces code which meets the tests. Swap roles.
- When new development comes up, ask to be assigned to tasks which force you to work with code you've not used before.
Even if you don't end up exposing yourself to all the darkest reaches of your colleagues codebase, you'll at least begin to notice enough patterns in the things your colleague does which might help you diagnose bugs faster next time.
answered Feb 5 '16 at 20:08
user52889
7,21531527
answered Feb 5 '16 at 20:08
user52889
7,21531527
answered Feb 5 '16 at 20:08
user52889
7,21531527
answered Feb 5 '16 at 20:08
user52889
7,21531527
7,21531527
2
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
suggest improvements |Â
2
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
2
2
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that.
– Amy Blankenship
Feb 5 '16 at 23:17
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
– Dunk
Feb 16 '16 at 20:27
suggest improvements |Â
up vote
4
down vote
Honest, direct communication is fine. Bring solutions, not problems. You can raise the following points with your boss:
- You noticed the problem with the production code was preventable.
- Your fix patched the problem over--but doesn't create stable, maintainable code.
- Recommend code reviews to avoid future problems.
Code reviews are magical places where junior developers can introduce new techniques and best practices into production, without ruffling feathers. The focus is on the code, not the person. Don't condescend, over-instruct, or generalize beyond the current example. Simply state that for this particular case, there is a useful pattern you've had success with. Be specific about a single issue that can arise for each change. "If we change this to that, it will leak memory. If we change this to that, it will fail gracefully for poor inputs, such as this, which has occurred before." In contentious situations like this, you "rotate the code"--everyone reviews the code, but the person to your left in the meeting makes the changes (or next tallest, or next birthday, etc.). Everyone benefits, and no one loses face at the time--although people who require the most changes become obvious over time.
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
Simple state that for this particular case, there is a useful pattern you've had success with.- The name for this is teaching.
– Joel Etherton
Feb 5 '16 at 20:01
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
1
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
suggest improvements |Â
up vote
4
down vote
Honest, direct communication is fine. Bring solutions, not problems. You can raise the following points with your boss:
- You noticed the problem with the production code was preventable.
- Your fix patched the problem over--but doesn't create stable, maintainable code.
- Recommend code reviews to avoid future problems.
Code reviews are magical places where junior developers can introduce new techniques and best practices into production, without ruffling feathers. The focus is on the code, not the person. Don't condescend, over-instruct, or generalize beyond the current example. Simply state that for this particular case, there is a useful pattern you've had success with. Be specific about a single issue that can arise for each change. "If we change this to that, it will leak memory. If we change this to that, it will fail gracefully for poor inputs, such as this, which has occurred before." In contentious situations like this, you "rotate the code"--everyone reviews the code, but the person to your left in the meeting makes the changes (or next tallest, or next birthday, etc.). Everyone benefits, and no one loses face at the time--although people who require the most changes become obvious over time.
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
Simple state that for this particular case, there is a useful pattern you've had success with.- The name for this is teaching.
– Joel Etherton
Feb 5 '16 at 20:01
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
1
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
Honest, direct communication is fine. Bring solutions, not problems. You can raise the following points with your boss:
- You noticed the problem with the production code was preventable.
- Your fix patched the problem over--but doesn't create stable, maintainable code.
- Recommend code reviews to avoid future problems.
Code reviews are magical places where junior developers can introduce new techniques and best practices into production, without ruffling feathers. The focus is on the code, not the person. Don't condescend, over-instruct, or generalize beyond the current example. Simply state that for this particular case, there is a useful pattern you've had success with. Be specific about a single issue that can arise for each change. "If we change this to that, it will leak memory. If we change this to that, it will fail gracefully for poor inputs, such as this, which has occurred before." In contentious situations like this, you "rotate the code"--everyone reviews the code, but the person to your left in the meeting makes the changes (or next tallest, or next birthday, etc.). Everyone benefits, and no one loses face at the time--although people who require the most changes become obvious over time.
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
Honest, direct communication is fine. Bring solutions, not problems. You can raise the following points with your boss:
- You noticed the problem with the production code was preventable.
- Your fix patched the problem over--but doesn't create stable, maintainable code.
- Recommend code reviews to avoid future problems.
Code reviews are magical places where junior developers can introduce new techniques and best practices into production, without ruffling feathers. The focus is on the code, not the person. Don't condescend, over-instruct, or generalize beyond the current example. Simply state that for this particular case, there is a useful pattern you've had success with. Be specific about a single issue that can arise for each change. "If we change this to that, it will leak memory. If we change this to that, it will fail gracefully for poor inputs, such as this, which has occurred before." In contentious situations like this, you "rotate the code"--everyone reviews the code, but the person to your left in the meeting makes the changes (or next tallest, or next birthday, etc.). Everyone benefits, and no one loses face at the time--although people who require the most changes become obvious over time.
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
edited Feb 5 '16 at 20:17
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
answered Feb 5 '16 at 19:17
jimm101
11.6k72753
11.6k72753
Simple state that for this particular case, there is a useful pattern you've had success with.- The name for this is teaching.
– Joel Etherton
Feb 5 '16 at 20:01
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
1
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
suggest improvements |Â
Simple state that for this particular case, there is a useful pattern you've had success with.- The name for this is teaching.
– Joel Etherton
Feb 5 '16 at 20:01
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
1
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
Simple state that for this particular case, there is a useful pattern you've had success with. - The name for this is teaching.– Joel Etherton
Feb 5 '16 at 20:01
Simple state that for this particular case, there is a useful pattern you've had success with. - The name for this is teaching.– Joel Etherton
Feb 5 '16 at 20:01
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
@JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
– jimm101
Feb 5 '16 at 20:19
1
1
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there.
– Joel Etherton
Feb 5 '16 at 20:26
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
Code reviews are not magical. Some developers are very defensive and that won't change in a code review.
– kevin cline
Feb 6 '16 at 1:18
suggest improvements |Â
up vote
2
down vote
Fix the problem
You can either continue the same "style" of coding and get the immediate problems fixed or take the time to fix the over-all problems plaguing this code set. Your boss will have to decide. That's why he gets the big bucks.
Hopefully, there will be some sort of postmortem on this problem and your team needs to decide if you're going to allow the other developer continue with the quick and dirty programming.
Again, your boss is going to have to decide how to move forward. I don't know why your boss doesn't enforce what appears to be a higher standard for coding on the sr programmer. The technical debt ultimately had to be paid by everyone.
All you can do is make suggestions and do your best given the constraints of your boss's decisions.
suggest improvements |Â
up vote
2
down vote
Fix the problem
You can either continue the same "style" of coding and get the immediate problems fixed or take the time to fix the over-all problems plaguing this code set. Your boss will have to decide. That's why he gets the big bucks.
Hopefully, there will be some sort of postmortem on this problem and your team needs to decide if you're going to allow the other developer continue with the quick and dirty programming.
Again, your boss is going to have to decide how to move forward. I don't know why your boss doesn't enforce what appears to be a higher standard for coding on the sr programmer. The technical debt ultimately had to be paid by everyone.
All you can do is make suggestions and do your best given the constraints of your boss's decisions.
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Fix the problem
You can either continue the same "style" of coding and get the immediate problems fixed or take the time to fix the over-all problems plaguing this code set. Your boss will have to decide. That's why he gets the big bucks.
Hopefully, there will be some sort of postmortem on this problem and your team needs to decide if you're going to allow the other developer continue with the quick and dirty programming.
Again, your boss is going to have to decide how to move forward. I don't know why your boss doesn't enforce what appears to be a higher standard for coding on the sr programmer. The technical debt ultimately had to be paid by everyone.
All you can do is make suggestions and do your best given the constraints of your boss's decisions.
Fix the problem
You can either continue the same "style" of coding and get the immediate problems fixed or take the time to fix the over-all problems plaguing this code set. Your boss will have to decide. That's why he gets the big bucks.
Hopefully, there will be some sort of postmortem on this problem and your team needs to decide if you're going to allow the other developer continue with the quick and dirty programming.
Again, your boss is going to have to decide how to move forward. I don't know why your boss doesn't enforce what appears to be a higher standard for coding on the sr programmer. The technical debt ultimately had to be paid by everyone.
All you can do is make suggestions and do your best given the constraints of your boss's decisions.
answered Feb 5 '16 at 19:52
user8365
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
If you work as a team you are Both responsable for the quality of the code (even if you did not write it). All code should be code reviewed and a consensus reached.
If you have trouble reaching consensus then install automated tools to do the validation only allow commits that pass the automated validation.
As how to handle your current situation.
- Say this code was not your project.
- You only fixed the specific bug (not the whole project/file) to prevent instability.
- Suggest how the processes can be improved overall.
answered Feb 5 '16 at 19:30
Martin York
953616
suggest improvements |Â
up vote
1
down vote
If you work as a team you are Both responsable for the quality of the code (even if you did not write it). All code should be code reviewed and a consensus reached.
If you have trouble reaching consensus then install automated tools to do the validation only allow commits that pass the automated validation.
As how to handle your current situation.
- Say this code was not your project.
- You only fixed the specific bug (not the whole project/file) to prevent instability.
- Suggest how the processes can be improved overall.
answered Feb 5 '16 at 19:30
Martin York
953616
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
If you work as a team you are Both responsable for the quality of the code (even if you did not write it). All code should be code reviewed and a consensus reached.
If you have trouble reaching consensus then install automated tools to do the validation only allow commits that pass the automated validation.
As how to handle your current situation.
- Say this code was not your project.
- You only fixed the specific bug (not the whole project/file) to prevent instability.
- Suggest how the processes can be improved overall.
answered Feb 5 '16 at 19:30
Martin York
953616
If you work as a team you are Both responsable for the quality of the code (even if you did not write it). All code should be code reviewed and a consensus reached.
If you have trouble reaching consensus then install automated tools to do the validation only allow commits that pass the automated validation.
As how to handle your current situation.
- Say this code was not your project.
- You only fixed the specific bug (not the whole project/file) to prevent instability.
- Suggest how the processes can be improved overall.
answered Feb 5 '16 at 19:30
Martin York
953616
answered Feb 5 '16 at 19:30
Martin York
953616
answered Feb 5 '16 at 19:30
Martin York
953616
answered Feb 5 '16 at 19:30
Martin York
953616
953616
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
- Meet with your director and explain your constructive disagreement with your team lead's coding style. Use tact.
- Come prepared with about 3 coding, architecture, or process examples that support your point of view.
- Depending upon the nature of the situation, and the personality of the team lead, you may want to include the team lead in this meeting.
- Explain your point of view, but do not argue with your director. Listen to his/her opinion. Be prepared to conclude the meeting in less than an hour.
- Leave the meeting. Finish your day. Go home. Have dinner. Go to sleep.
- During your commute to work on the next business day, evaluate your meeting with your director. Was he/she fair?
- If 'Yes' (even if he/she did not agree with your point of view), then be prepared to adjust your way of doing things (other people have responded with some great advice).
- If 'No', or if you feel that you cannot coexist with this team lead, then you have two options: 1. Ask your director if you can transfer to another department. 2. Start looking for a new job.
More on the 'Start looking for a new job' advice:
- Pursue this option only as a last resort.
- In the workplace (and in life in general), try your best to see the other person's point of view.
- But ultimately, if you're unable to make things work, you should start looking for a new job. Life is just too short and coding jobs are plentiful.
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
suggest improvements |Â
up vote
1
down vote
- Meet with your director and explain your constructive disagreement with your team lead's coding style. Use tact.
- Come prepared with about 3 coding, architecture, or process examples that support your point of view.
- Depending upon the nature of the situation, and the personality of the team lead, you may want to include the team lead in this meeting.
- Explain your point of view, but do not argue with your director. Listen to his/her opinion. Be prepared to conclude the meeting in less than an hour.
- Leave the meeting. Finish your day. Go home. Have dinner. Go to sleep.
- During your commute to work on the next business day, evaluate your meeting with your director. Was he/she fair?
- If 'Yes' (even if he/she did not agree with your point of view), then be prepared to adjust your way of doing things (other people have responded with some great advice).
- If 'No', or if you feel that you cannot coexist with this team lead, then you have two options: 1. Ask your director if you can transfer to another department. 2. Start looking for a new job.
More on the 'Start looking for a new job' advice:
- Pursue this option only as a last resort.
- In the workplace (and in life in general), try your best to see the other person's point of view.
- But ultimately, if you're unable to make things work, you should start looking for a new job. Life is just too short and coding jobs are plentiful.
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
- Meet with your director and explain your constructive disagreement with your team lead's coding style. Use tact.
- Come prepared with about 3 coding, architecture, or process examples that support your point of view.
- Depending upon the nature of the situation, and the personality of the team lead, you may want to include the team lead in this meeting.
- Explain your point of view, but do not argue with your director. Listen to his/her opinion. Be prepared to conclude the meeting in less than an hour.
- Leave the meeting. Finish your day. Go home. Have dinner. Go to sleep.
- During your commute to work on the next business day, evaluate your meeting with your director. Was he/she fair?
- If 'Yes' (even if he/she did not agree with your point of view), then be prepared to adjust your way of doing things (other people have responded with some great advice).
- If 'No', or if you feel that you cannot coexist with this team lead, then you have two options: 1. Ask your director if you can transfer to another department. 2. Start looking for a new job.
More on the 'Start looking for a new job' advice:
- Pursue this option only as a last resort.
- In the workplace (and in life in general), try your best to see the other person's point of view.
- But ultimately, if you're unable to make things work, you should start looking for a new job. Life is just too short and coding jobs are plentiful.
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
- Meet with your director and explain your constructive disagreement with your team lead's coding style. Use tact.
- Come prepared with about 3 coding, architecture, or process examples that support your point of view.
- Depending upon the nature of the situation, and the personality of the team lead, you may want to include the team lead in this meeting.
- Explain your point of view, but do not argue with your director. Listen to his/her opinion. Be prepared to conclude the meeting in less than an hour.
- Leave the meeting. Finish your day. Go home. Have dinner. Go to sleep.
- During your commute to work on the next business day, evaluate your meeting with your director. Was he/she fair?
- If 'Yes' (even if he/she did not agree with your point of view), then be prepared to adjust your way of doing things (other people have responded with some great advice).
- If 'No', or if you feel that you cannot coexist with this team lead, then you have two options: 1. Ask your director if you can transfer to another department. 2. Start looking for a new job.
More on the 'Start looking for a new job' advice:
- Pursue this option only as a last resort.
- In the workplace (and in life in general), try your best to see the other person's point of view.
- But ultimately, if you're unable to make things work, you should start looking for a new job. Life is just too short and coding jobs are plentiful.
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
answered Feb 5 '16 at 21:15
Jim G.
11.8k105373
11.8k105373
suggest improvements |Â
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%2f61635%2fhow-to-deal-with-incompetent-lead%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
3
If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team.
– Joel Etherton
Feb 5 '16 at 20:00
5
As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction.
– Joel Etherton
Feb 5 '16 at 20:03
1
I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.– Jim G.
Feb 5 '16 at 21:05
3
If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards?
– Carson63000
Feb 5 '16 at 21:48
1
@JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
– Lilienthal♦
Feb 8 '16 at 12:54