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.

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?

• First, it’s obviously a question of quality of code. Code reviews help detecting bugs and prevent bad implementations.
• Second, it will teach you new ways to code, or to solve a problem and it will ensure that at least another developer has seen what is going on in this part of the application (if your application is growing fast, there is a chance you don’t keep track of important changes or implementations).
• And finally, a part that seems really important to me: it helps reducing tensions within the team. If you introduced a bug in the app, you’re not the only one responsible for it. The whole team is responsible. This way you can’t tell “This guy or this girl did that”. The one who merges it is equally responsible. You will then share failures and victories together. I do trainings sometimes and I am always shocked by how the coding and merging process can influence on the global ambiance. A mandatory code review process does not ensure by itself a friendly and united team. But no process at all with no shared responsibility between developers guarantees tensions, for sure.

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.

• Implementing a catalog import with RabbitMQ and Elasticsearch (I took that example randomly, for sure)
• Synchronizing two databases
• Fixing a lot of broken translations

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.