Mixing
How to educate peers on quality practices for new technologies?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
I'm on a team that owns most of the core libraries for one of my company's platforms. We are also responsible for educating other teams when they first start developing microservices for that platform, then we switch to more of an advice and support role. It's primarily written in Scala, and is the first exposure most of the team members have had to a functional paradigm beyond simple exercises from school, if they even had that much.
What we often see is several months after we leave the initial intensive period where we are doing a lot of pair programming and thoroughly reviewing every pull request, we will happen to look in their code and see things that frankly are bad functional style. These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway.
So, we're looking for some way to effectively keep the education ongoing. A fun incentive or periodic activity, perhaps? Keep in mind our team is in a very good position to influence and invite, but not to demand. Any ideas?
quality continuing-education
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
suggest improvements |Â
up vote
1
down vote
favorite
I'm on a team that owns most of the core libraries for one of my company's platforms. We are also responsible for educating other teams when they first start developing microservices for that platform, then we switch to more of an advice and support role. It's primarily written in Scala, and is the first exposure most of the team members have had to a functional paradigm beyond simple exercises from school, if they even had that much.
What we often see is several months after we leave the initial intensive period where we are doing a lot of pair programming and thoroughly reviewing every pull request, we will happen to look in their code and see things that frankly are bad functional style. These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway.
So, we're looking for some way to effectively keep the education ongoing. A fun incentive or periodic activity, perhaps? Keep in mind our team is in a very good position to influence and invite, but not to demand. Any ideas?
quality continuing-education
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
Why not do periodic reviews rather than review everything?
– Kilisi
May 12 '16 at 6:07
3
It seems like you already know that code reviews are the answer. Shouldn't your question be how to do them effectively (e.g. across time zones, etc.)?
– Brandin
May 12 '16 at 8:43
I'm pretty sure they will take easy path and not using the functional libraries and do the job imperative. If you don't guide them.
– lambdapool
May 12 '16 at 10:15
suggest improvements |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm on a team that owns most of the core libraries for one of my company's platforms. We are also responsible for educating other teams when they first start developing microservices for that platform, then we switch to more of an advice and support role. It's primarily written in Scala, and is the first exposure most of the team members have had to a functional paradigm beyond simple exercises from school, if they even had that much.
What we often see is several months after we leave the initial intensive period where we are doing a lot of pair programming and thoroughly reviewing every pull request, we will happen to look in their code and see things that frankly are bad functional style. These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway.
So, we're looking for some way to effectively keep the education ongoing. A fun incentive or periodic activity, perhaps? Keep in mind our team is in a very good position to influence and invite, but not to demand. Any ideas?
quality continuing-education
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
I'm on a team that owns most of the core libraries for one of my company's platforms. We are also responsible for educating other teams when they first start developing microservices for that platform, then we switch to more of an advice and support role. It's primarily written in Scala, and is the first exposure most of the team members have had to a functional paradigm beyond simple exercises from school, if they even had that much.
What we often see is several months after we leave the initial intensive period where we are doing a lot of pair programming and thoroughly reviewing every pull request, we will happen to look in their code and see things that frankly are bad functional style. These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway.
So, we're looking for some way to effectively keep the education ongoing. A fun incentive or periodic activity, perhaps? Keep in mind our team is in a very good position to influence and invite, but not to demand. Any ideas?
quality continuing-education
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
asked May 12 '16 at 4:43
Karl Bielefeldt
10.4k31830
10.4k31830
Why not do periodic reviews rather than review everything?
– Kilisi
May 12 '16 at 6:07
3
It seems like you already know that code reviews are the answer. Shouldn't your question be how to do them effectively (e.g. across time zones, etc.)?
– Brandin
May 12 '16 at 8:43
I'm pretty sure they will take easy path and not using the functional libraries and do the job imperative. If you don't guide them.
– lambdapool
May 12 '16 at 10:15
suggest improvements |Â
Why not do periodic reviews rather than review everything?
– Kilisi
May 12 '16 at 6:07
3
It seems like you already know that code reviews are the answer. Shouldn't your question be how to do them effectively (e.g. across time zones, etc.)?
– Brandin
May 12 '16 at 8:43
I'm pretty sure they will take easy path and not using the functional libraries and do the job imperative. If you don't guide them.
– lambdapool
May 12 '16 at 10:15
Why not do periodic reviews rather than review everything?
– Kilisi
May 12 '16 at 6:07
Why not do periodic reviews rather than review everything?
– Kilisi
May 12 '16 at 6:07
3
3
It seems like you already know that code reviews are the answer. Shouldn't your question be how to do them effectively (e.g. across time zones, etc.)?
– Brandin
May 12 '16 at 8:43
It seems like you already know that code reviews are the answer. Shouldn't your question be how to do them effectively (e.g. across time zones, etc.)?
– Brandin
May 12 '16 at 8:43
I'm pretty sure they will take easy path and not using the functional libraries and do the job imperative. If you don't guide them.
– lambdapool
May 12 '16 at 10:15
I'm pretty sure they will take easy path and not using the functional libraries and do the job imperative. If you don't guide them.
– lambdapool
May 12 '16 at 10:15
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
I'm on a team that owns most of the core libraries for one of my company's platforms
This sounds like "our team getting things right is really important."
These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway
Ah, the problem isn't so much you don't know a really great solution but do not have time for it.
Code reviews have as their entire purpose to address issues like this. Good code reviews with a team willing to learn results in higher quality code over the long term as well as better education.
Depending on your role and team, I would consider adopting some sort of unofficial policy regarding code reviews:
- Every piece of code requires a senior +1 before being merged
- All pieces of code require +1 from two team members
- No one can check code in without having it looked over by another person
The reality is you ARE going to deal with problems that get merged. The question is whether you will deal with them prior to being merged (through a review) or after they are merged and become technical debt.
Another way to address this is to have a better transition process. You made it sound like a new hire goes through several months of heavy pair programming/review and then is set free to do things themselves. A few things here which will help:
- Make 100% sure the new people are the ones typing the code. They should have their IDE up, they should be typing, and the senior should be guiding them -- not a situation where the junior just watches the senior type
- This is going to feel miserably slow for anyone who is used to the senior typing and junior watching
- The junior watching the senior type is pretty useless from a teaching perspective, because they aren't doing. Most people learn from doing, not watching
- Have a gradual transition plan away from the heavy mentoring. Don't just let them go 100% loose until you have confidence they can achieve.
If resources are the problem, talk with your manager. Explain it just as you have said it here. Saying that your team does not have the resources it needs to effectively guarantee quality code is written. Explain what the outcome of this would be in your situation. Ask what your team can do to get more resources. Your manager should care about this situation at least somewhat.
And last, consider making part of your interview process include asking about functional programming. It's better to hire 1 person who can work efficiently and independently than several you have to babysit.
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
suggest improvements |Â
up vote
0
down vote
Scala usually blow up new minds because of the functional and lambdas and monads concepts. You probably should foster some training group, share samples inside a intern SharePoint or institutional portal.
People from java OO struggle at those concepts because they are too way diferente and you can count they will try take the easy path most of times, in other ways, doing things without functional minds.
answered May 12 '16 at 10:14
lambdapool
111110
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I'm on a team that owns most of the core libraries for one of my company's platforms
This sounds like "our team getting things right is really important."
These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway
Ah, the problem isn't so much you don't know a really great solution but do not have time for it.
Code reviews have as their entire purpose to address issues like this. Good code reviews with a team willing to learn results in higher quality code over the long term as well as better education.
Depending on your role and team, I would consider adopting some sort of unofficial policy regarding code reviews:
- Every piece of code requires a senior +1 before being merged
- All pieces of code require +1 from two team members
- No one can check code in without having it looked over by another person
The reality is you ARE going to deal with problems that get merged. The question is whether you will deal with them prior to being merged (through a review) or after they are merged and become technical debt.
Another way to address this is to have a better transition process. You made it sound like a new hire goes through several months of heavy pair programming/review and then is set free to do things themselves. A few things here which will help:
- Make 100% sure the new people are the ones typing the code. They should have their IDE up, they should be typing, and the senior should be guiding them -- not a situation where the junior just watches the senior type
- This is going to feel miserably slow for anyone who is used to the senior typing and junior watching
- The junior watching the senior type is pretty useless from a teaching perspective, because they aren't doing. Most people learn from doing, not watching
- Have a gradual transition plan away from the heavy mentoring. Don't just let them go 100% loose until you have confidence they can achieve.
If resources are the problem, talk with your manager. Explain it just as you have said it here. Saying that your team does not have the resources it needs to effectively guarantee quality code is written. Explain what the outcome of this would be in your situation. Ask what your team can do to get more resources. Your manager should care about this situation at least somewhat.
And last, consider making part of your interview process include asking about functional programming. It's better to hire 1 person who can work efficiently and independently than several you have to babysit.
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
suggest improvements |Â
up vote
1
down vote
I'm on a team that owns most of the core libraries for one of my company's platforms
This sounds like "our team getting things right is really important."
These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway
Ah, the problem isn't so much you don't know a really great solution but do not have time for it.
Code reviews have as their entire purpose to address issues like this. Good code reviews with a team willing to learn results in higher quality code over the long term as well as better education.
Depending on your role and team, I would consider adopting some sort of unofficial policy regarding code reviews:
- Every piece of code requires a senior +1 before being merged
- All pieces of code require +1 from two team members
- No one can check code in without having it looked over by another person
The reality is you ARE going to deal with problems that get merged. The question is whether you will deal with them prior to being merged (through a review) or after they are merged and become technical debt.
Another way to address this is to have a better transition process. You made it sound like a new hire goes through several months of heavy pair programming/review and then is set free to do things themselves. A few things here which will help:
- Make 100% sure the new people are the ones typing the code. They should have their IDE up, they should be typing, and the senior should be guiding them -- not a situation where the junior just watches the senior type
- This is going to feel miserably slow for anyone who is used to the senior typing and junior watching
- The junior watching the senior type is pretty useless from a teaching perspective, because they aren't doing. Most people learn from doing, not watching
- Have a gradual transition plan away from the heavy mentoring. Don't just let them go 100% loose until you have confidence they can achieve.
If resources are the problem, talk with your manager. Explain it just as you have said it here. Saying that your team does not have the resources it needs to effectively guarantee quality code is written. Explain what the outcome of this would be in your situation. Ask what your team can do to get more resources. Your manager should care about this situation at least somewhat.
And last, consider making part of your interview process include asking about functional programming. It's better to hire 1 person who can work efficiently and independently than several you have to babysit.
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
I'm on a team that owns most of the core libraries for one of my company's platforms
This sounds like "our team getting things right is really important."
These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway
Ah, the problem isn't so much you don't know a really great solution but do not have time for it.
Code reviews have as their entire purpose to address issues like this. Good code reviews with a team willing to learn results in higher quality code over the long term as well as better education.
Depending on your role and team, I would consider adopting some sort of unofficial policy regarding code reviews:
- Every piece of code requires a senior +1 before being merged
- All pieces of code require +1 from two team members
- No one can check code in without having it looked over by another person
The reality is you ARE going to deal with problems that get merged. The question is whether you will deal with them prior to being merged (through a review) or after they are merged and become technical debt.
Another way to address this is to have a better transition process. You made it sound like a new hire goes through several months of heavy pair programming/review and then is set free to do things themselves. A few things here which will help:
- Make 100% sure the new people are the ones typing the code. They should have their IDE up, they should be typing, and the senior should be guiding them -- not a situation where the junior just watches the senior type
- This is going to feel miserably slow for anyone who is used to the senior typing and junior watching
- The junior watching the senior type is pretty useless from a teaching perspective, because they aren't doing. Most people learn from doing, not watching
- Have a gradual transition plan away from the heavy mentoring. Don't just let them go 100% loose until you have confidence they can achieve.
If resources are the problem, talk with your manager. Explain it just as you have said it here. Saying that your team does not have the resources it needs to effectively guarantee quality code is written. Explain what the outcome of this would be in your situation. Ask what your team can do to get more resources. Your manager should care about this situation at least somewhat.
And last, consider making part of your interview process include asking about functional programming. It's better to hire 1 person who can work efficiently and independently than several you have to babysit.
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
I'm on a team that owns most of the core libraries for one of my company's platforms
This sounds like "our team getting things right is really important."
These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway
Ah, the problem isn't so much you don't know a really great solution but do not have time for it.
Code reviews have as their entire purpose to address issues like this. Good code reviews with a team willing to learn results in higher quality code over the long term as well as better education.
Depending on your role and team, I would consider adopting some sort of unofficial policy regarding code reviews:
- Every piece of code requires a senior +1 before being merged
- All pieces of code require +1 from two team members
- No one can check code in without having it looked over by another person
The reality is you ARE going to deal with problems that get merged. The question is whether you will deal with them prior to being merged (through a review) or after they are merged and become technical debt.
Another way to address this is to have a better transition process. You made it sound like a new hire goes through several months of heavy pair programming/review and then is set free to do things themselves. A few things here which will help:
- Make 100% sure the new people are the ones typing the code. They should have their IDE up, they should be typing, and the senior should be guiding them -- not a situation where the junior just watches the senior type
- This is going to feel miserably slow for anyone who is used to the senior typing and junior watching
- The junior watching the senior type is pretty useless from a teaching perspective, because they aren't doing. Most people learn from doing, not watching
- Have a gradual transition plan away from the heavy mentoring. Don't just let them go 100% loose until you have confidence they can achieve.
If resources are the problem, talk with your manager. Explain it just as you have said it here. Saying that your team does not have the resources it needs to effectively guarantee quality code is written. Explain what the outcome of this would be in your situation. Ask what your team can do to get more resources. Your manager should care about this situation at least somewhat.
And last, consider making part of your interview process include asking about functional programming. It's better to hire 1 person who can work efficiently and independently than several you have to babysit.
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
answered May 12 '16 at 12:24
Elysian Fields♦
96.7k46292449
96.7k46292449
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
Scala usually blow up new minds because of the functional and lambdas and monads concepts. You probably should foster some training group, share samples inside a intern SharePoint or institutional portal.
People from java OO struggle at those concepts because they are too way diferente and you can count they will try take the easy path most of times, in other ways, doing things without functional minds.
answered May 12 '16 at 10:14
lambdapool
111110
suggest improvements |Â
up vote
0
down vote
Scala usually blow up new minds because of the functional and lambdas and monads concepts. You probably should foster some training group, share samples inside a intern SharePoint or institutional portal.
People from java OO struggle at those concepts because they are too way diferente and you can count they will try take the easy path most of times, in other ways, doing things without functional minds.
answered May 12 '16 at 10:14
lambdapool
111110
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
Scala usually blow up new minds because of the functional and lambdas and monads concepts. You probably should foster some training group, share samples inside a intern SharePoint or institutional portal.
People from java OO struggle at those concepts because they are too way diferente and you can count they will try take the easy path most of times, in other ways, doing things without functional minds.
answered May 12 '16 at 10:14
lambdapool
111110
Scala usually blow up new minds because of the functional and lambdas and monads concepts. You probably should foster some training group, share samples inside a intern SharePoint or institutional portal.
People from java OO struggle at those concepts because they are too way diferente and you can count they will try take the easy path most of times, in other ways, doing things without functional minds.
answered May 12 '16 at 10:14
lambdapool
111110
answered May 12 '16 at 10:14
lambdapool
111110
answered May 12 '16 at 10:14
lambdapool
111110
answered May 12 '16 at 10:14
lambdapool
111110
111110
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%2f66997%2fhow-to-educate-peers-on-quality-practices-for-new-technologies%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
Why not do periodic reviews rather than review everything?
– Kilisi
May 12 '16 at 6:07
3
It seems like you already know that code reviews are the answer. Shouldn't your question be how to do them effectively (e.g. across time zones, etc.)?
– Brandin
May 12 '16 at 8:43
I'm pretty sure they will take easy path and not using the functional libraries and do the job imperative. If you don't guide them.
– lambdapool
May 12 '16 at 10:15