Mixing
How can I encourage my coworkers to produce better quality code? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
5
down vote
favorite
I'm a team lead for a small group of programmers. We share several projects with other teams. Lately the quality of two other teams' code has deteriorated to the point where it is slowing us down and causing maintainability issues. I've raised this diplomatically with a couple of individuals directly, but they become defensive and dismissive. I don't have the clout to go over their heads, and ultimately I need to work with these people so I don't want to annoy them too much.
I'm wondering if there's a process or a forum that can help improve the code for everyone? We already have basic things like well-documented coding standards, tests, linting, code reviews, etc.
But I'm thinking there's more we could do. Maybe a system where developers can anonymously praise or criticise others' code. Or maybe a type of informal meeting where someone can present some problematic code and describe the issues it causes and suggest a refactor. The original author could have the opportunity to defend their work, and then everyone gets to vote on the outcome... if there's a way to do that without being outrageously confrontational.
Has anyone tried something similar, and how did it work out? Any other suggestions? (Apologies for the open-ended questions)
colleagues team process code quality
asked Aug 31 at 14:08
manannan
344
closed as too broad by gnat, Twyxz, GOATNine, JimmyB, IDrinkandIKnowThings Sep 5 at 14:10
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
5
down vote
favorite
I'm a team lead for a small group of programmers. We share several projects with other teams. Lately the quality of two other teams' code has deteriorated to the point where it is slowing us down and causing maintainability issues. I've raised this diplomatically with a couple of individuals directly, but they become defensive and dismissive. I don't have the clout to go over their heads, and ultimately I need to work with these people so I don't want to annoy them too much.
I'm wondering if there's a process or a forum that can help improve the code for everyone? We already have basic things like well-documented coding standards, tests, linting, code reviews, etc.
But I'm thinking there's more we could do. Maybe a system where developers can anonymously praise or criticise others' code. Or maybe a type of informal meeting where someone can present some problematic code and describe the issues it causes and suggest a refactor. The original author could have the opportunity to defend their work, and then everyone gets to vote on the outcome... if there's a way to do that without being outrageously confrontational.
Has anyone tried something similar, and how did it work out? Any other suggestions? (Apologies for the open-ended questions)
colleagues team process code quality
asked Aug 31 at 14:08
manannan
344
closed as too broad by gnat, Twyxz, GOATNine, JimmyB, IDrinkandIKnowThings Sep 5 at 14:10
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation?
– Juha Untinen
Aug 31 at 14:39
Have you listened to the defensive arguments? What did they told you?
– Josef
Aug 31 at 14:52
@JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets.
– manannan
Aug 31 at 15:17
@Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run.
– manannan
Aug 31 at 15:25
@manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem.
– Josef
Aug 31 at 17:35
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I'm a team lead for a small group of programmers. We share several projects with other teams. Lately the quality of two other teams' code has deteriorated to the point where it is slowing us down and causing maintainability issues. I've raised this diplomatically with a couple of individuals directly, but they become defensive and dismissive. I don't have the clout to go over their heads, and ultimately I need to work with these people so I don't want to annoy them too much.
I'm wondering if there's a process or a forum that can help improve the code for everyone? We already have basic things like well-documented coding standards, tests, linting, code reviews, etc.
But I'm thinking there's more we could do. Maybe a system where developers can anonymously praise or criticise others' code. Or maybe a type of informal meeting where someone can present some problematic code and describe the issues it causes and suggest a refactor. The original author could have the opportunity to defend their work, and then everyone gets to vote on the outcome... if there's a way to do that without being outrageously confrontational.
Has anyone tried something similar, and how did it work out? Any other suggestions? (Apologies for the open-ended questions)
colleagues team process code quality
asked Aug 31 at 14:08
manannan
344
I'm a team lead for a small group of programmers. We share several projects with other teams. Lately the quality of two other teams' code has deteriorated to the point where it is slowing us down and causing maintainability issues. I've raised this diplomatically with a couple of individuals directly, but they become defensive and dismissive. I don't have the clout to go over their heads, and ultimately I need to work with these people so I don't want to annoy them too much.
I'm wondering if there's a process or a forum that can help improve the code for everyone? We already have basic things like well-documented coding standards, tests, linting, code reviews, etc.
But I'm thinking there's more we could do. Maybe a system where developers can anonymously praise or criticise others' code. Or maybe a type of informal meeting where someone can present some problematic code and describe the issues it causes and suggest a refactor. The original author could have the opportunity to defend their work, and then everyone gets to vote on the outcome... if there's a way to do that without being outrageously confrontational.
Has anyone tried something similar, and how did it work out? Any other suggestions? (Apologies for the open-ended questions)
colleagues team process code quality
asked Aug 31 at 14:08
manannan
344
asked Aug 31 at 14:08
manannan
344
asked Aug 31 at 14:08
manannan
344
asked Aug 31 at 14:08
manannan
344
344
closed as too broad by gnat, Twyxz, GOATNine, JimmyB, IDrinkandIKnowThings Sep 5 at 14:10
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as too broad by gnat, Twyxz, GOATNine, JimmyB, IDrinkandIKnowThings Sep 5 at 14:10
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation?
– Juha Untinen
Aug 31 at 14:39
Have you listened to the defensive arguments? What did they told you?
– Josef
Aug 31 at 14:52
@JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets.
– manannan
Aug 31 at 15:17
@Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run.
– manannan
Aug 31 at 15:25
@manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem.
– Josef
Aug 31 at 17:35
add a comment |Â
Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation?
– Juha Untinen
Aug 31 at 14:39
Have you listened to the defensive arguments? What did they told you?
– Josef
Aug 31 at 14:52
@JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets.
– manannan
Aug 31 at 15:17
@Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run.
– manannan
Aug 31 at 15:25
@manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem.
– Josef
Aug 31 at 17:35
Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation?
– Juha Untinen
Aug 31 at 14:39
Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation?
– Juha Untinen
Aug 31 at 14:39
Have you listened to the defensive arguments? What did they told you?
– Josef
Aug 31 at 14:52
Have you listened to the defensive arguments? What did they told you?
– Josef
Aug 31 at 14:52
@JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets.
– manannan
Aug 31 at 15:17
@JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets.
– manannan
Aug 31 at 15:17
@Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run.
– manannan
Aug 31 at 15:25
@Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run.
– manannan
Aug 31 at 15:25
@manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem.
– Josef
Aug 31 at 17:35
@manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem.
– Josef
Aug 31 at 17:35
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
If time is the highest priority, then you're not going to get quality. It sounds like you have all the usual standards in place, just no time to actually enforce them.
You don't say if you have a formal change control process.
If someone raises a ticket for a new feature or a bug fix, the ticket needs to identify what needs to be done. Someone gets assigned to do it. But the updated code doesn't get committed to the main build until it's been passed by a change control board (a few more senior members of the project). They don't approve it without the evidence that it's passed static code analysis, peer review and testing. Only once the CCB are happy does the code get committed and the ticket closed.
answered Aug 31 at 22:58
Simon B
2,5672716
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
add a comment |Â
up vote
11
down vote
I don't have the clout to go over their heads
You're the team lead, this gives you the clout.
If the problems are with another team, you should raise this with their team lead and discuss the issue of the code quality that's effecting everyone.
Have a meeting with them with a view to increasing quality across the board.
Trying out new processes probably won't work as you've already put coding quality/standard processes in place that clearly aren't working well enough. Adding another one won't improve quality, it'll just add more of a burden to everyone else.
Tackle this as a team of team leads.
answered Aug 31 at 14:16
Snow♦
51.5k46170213
1
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
4
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
If time is the highest priority, then you're not going to get quality. It sounds like you have all the usual standards in place, just no time to actually enforce them.
You don't say if you have a formal change control process.
If someone raises a ticket for a new feature or a bug fix, the ticket needs to identify what needs to be done. Someone gets assigned to do it. But the updated code doesn't get committed to the main build until it's been passed by a change control board (a few more senior members of the project). They don't approve it without the evidence that it's passed static code analysis, peer review and testing. Only once the CCB are happy does the code get committed and the ticket closed.
answered Aug 31 at 22:58
Simon B
2,5672716
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
add a comment |Â
up vote
1
down vote
accepted
If time is the highest priority, then you're not going to get quality. It sounds like you have all the usual standards in place, just no time to actually enforce them.
You don't say if you have a formal change control process.
If someone raises a ticket for a new feature or a bug fix, the ticket needs to identify what needs to be done. Someone gets assigned to do it. But the updated code doesn't get committed to the main build until it's been passed by a change control board (a few more senior members of the project). They don't approve it without the evidence that it's passed static code analysis, peer review and testing. Only once the CCB are happy does the code get committed and the ticket closed.
answered Aug 31 at 22:58
Simon B
2,5672716
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
If time is the highest priority, then you're not going to get quality. It sounds like you have all the usual standards in place, just no time to actually enforce them.
You don't say if you have a formal change control process.
If someone raises a ticket for a new feature or a bug fix, the ticket needs to identify what needs to be done. Someone gets assigned to do it. But the updated code doesn't get committed to the main build until it's been passed by a change control board (a few more senior members of the project). They don't approve it without the evidence that it's passed static code analysis, peer review and testing. Only once the CCB are happy does the code get committed and the ticket closed.
answered Aug 31 at 22:58
Simon B
2,5672716
If time is the highest priority, then you're not going to get quality. It sounds like you have all the usual standards in place, just no time to actually enforce them.
You don't say if you have a formal change control process.
If someone raises a ticket for a new feature or a bug fix, the ticket needs to identify what needs to be done. Someone gets assigned to do it. But the updated code doesn't get committed to the main build until it's been passed by a change control board (a few more senior members of the project). They don't approve it without the evidence that it's passed static code analysis, peer review and testing. Only once the CCB are happy does the code get committed and the ticket closed.
answered Aug 31 at 22:58
Simon B
2,5672716
answered Aug 31 at 22:58
Simon B
2,5672716
answered Aug 31 at 22:58
Simon B
2,5672716
answered Aug 31 at 22:58
Simon B
2,5672716
2,5672716
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
add a comment |Â
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development.
– manannan
Sep 1 at 17:26
add a comment |Â
up vote
11
down vote
I don't have the clout to go over their heads
You're the team lead, this gives you the clout.
If the problems are with another team, you should raise this with their team lead and discuss the issue of the code quality that's effecting everyone.
Have a meeting with them with a view to increasing quality across the board.
Trying out new processes probably won't work as you've already put coding quality/standard processes in place that clearly aren't working well enough. Adding another one won't improve quality, it'll just add more of a burden to everyone else.
Tackle this as a team of team leads.
answered Aug 31 at 14:16
Snow♦
51.5k46170213
1
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
4
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
add a comment |Â
up vote
11
down vote
I don't have the clout to go over their heads
You're the team lead, this gives you the clout.
If the problems are with another team, you should raise this with their team lead and discuss the issue of the code quality that's effecting everyone.
Have a meeting with them with a view to increasing quality across the board.
Trying out new processes probably won't work as you've already put coding quality/standard processes in place that clearly aren't working well enough. Adding another one won't improve quality, it'll just add more of a burden to everyone else.
Tackle this as a team of team leads.
answered Aug 31 at 14:16
Snow♦
51.5k46170213
1
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
4
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
add a comment |Â
up vote
11
down vote
up vote
11
down vote
I don't have the clout to go over their heads
You're the team lead, this gives you the clout.
If the problems are with another team, you should raise this with their team lead and discuss the issue of the code quality that's effecting everyone.
Have a meeting with them with a view to increasing quality across the board.
Trying out new processes probably won't work as you've already put coding quality/standard processes in place that clearly aren't working well enough. Adding another one won't improve quality, it'll just add more of a burden to everyone else.
Tackle this as a team of team leads.
answered Aug 31 at 14:16
Snow♦
51.5k46170213
I don't have the clout to go over their heads
You're the team lead, this gives you the clout.
If the problems are with another team, you should raise this with their team lead and discuss the issue of the code quality that's effecting everyone.
Have a meeting with them with a view to increasing quality across the board.
Trying out new processes probably won't work as you've already put coding quality/standard processes in place that clearly aren't working well enough. Adding another one won't improve quality, it'll just add more of a burden to everyone else.
Tackle this as a team of team leads.
answered Aug 31 at 14:16
Snow♦
51.5k46170213
answered Aug 31 at 14:16
Snow♦
51.5k46170213
answered Aug 31 at 14:16
Snow♦
51.5k46170213
answered Aug 31 at 14:16
Snow♦
51.5k46170213
51.5k46170213
1
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
4
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
add a comment |Â
1
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
4
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
1
1
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone.
– manannan
Aug 31 at 14:28
4
4
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
Then discuss it with the team leads that are producing decent quality code and work together.
– Snow♦
Aug 31 at 14:40
add a comment |Â
Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation?
– Juha Untinen
Aug 31 at 14:39
Have you listened to the defensive arguments? What did they told you?
– Josef
Aug 31 at 14:52
@JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets.
– manannan
Aug 31 at 15:17
@Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run.
– manannan
Aug 31 at 15:25
@manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem.
– Josef
Aug 31 at 17:35