How to educate peers on quality practices for new technologies?

Question

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?

Answer 1

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.

Answer 2

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.