Lessons learned about Bus Factor (2/5): Balancing the level of your team

Thu Sep 28 2017

Lessons learned about Bus Factor (2/5): Balancing the level of your team

This series of articles is taken from a talk I gave at the Berlin PHP Meetup.

A cute kitten

Image by allenran 917 (license CC BY)

This cute kitten has absolutely nothing to do with Bus Factor, unlike the first post of this series. Now we’re here, let’s dive into the lessons I learned about how to share knowledge inside your current coding team.

Code Reviews

I know this one is a big classic in the industry, but I think it is always good to emphasize it as a general advice. In my company we automatically do a code review for every feature or every fix. You can’t merge your own pull requests.

Why that?

Code reviews are definitely a great tool. But it is not enough. Because we all know this moment when you’re tired and stressed and you have to review 2000 lines of code at 6pm. In this case you sometimes close your eyes on something you don’t understand cause you know… “f*** it, let’s merge it”. If you have fat pull requests to review, it is a good idea to ask your colleague to present you their work and to review it in pair.

Improve the level of your juniors

Let’s say you have two seniors in your team and one junior. Here is what usually happens.

You are doing your sprint planning and you have 3 features/fix requests.

The first two are complex ones. The final one is a simple (but quite boring) task. Right now, the junior developer is panicking cause they don’t have any clue how to handle the two complex tasks and they hope they are not asked to do these tasks. Well, actually it’s not a problem, because the two senior developers are already discussing how fun it will be to deal with these complex issues, and start talking about a new esoteric and exciting paradigm they want to try. The junior is relieved and every one is happy…

For now.

Because sooner or later, this junior developer will probably have to dive alone into this code, and spend a stressful day first trying to understand the implementation and then trying to fix it. And we’re back to my little story from the beginning. Also, if we always give the most simple tasks to our junior developers, how can we expect them to level up?

Here is a simple but smart solution.

Do not always give the most complex thing to do, to the best developer.

Regularly (not always), ask your junior developer, if they agree, to take one of the most complex tasks. The fact that they take it does not mean at all that they must be alone on this. Tell them that they can ask you any questions they want at any point, and that you can do pair programming with them to solve this problem. Make everyone comfortable, and explain to the junior that it’s obviously not a shame if they have no clue how to do this. We all start at one point, and there is no problem being lost with a new technology or paradigm.

In general the junior developer will accept the offer, with a bit of fear. They will be very happy soon to have responsibilities in this team and to finally understand this new pattern or language.

Pair programming is a great tool, because (unlike code reviews) it does not only give you the result, but also the process of thought of your colleagues. If I think about my own experience, pair programming or just discussing with a more experimented developer about a future feature were the most rewarding moments in my short career. These moments are probably the ones when we learn the most how to think and code.

Next time, we will see how to make our code more explicit to ensure that a new comer will find their way in it.