Implementing new developers

It is Monday morning 8 o’clock. You just entered the building of your new employee and are a little nervous, but also exited. A few moments later you are already sitting in front of a computer in a room with your new team. Everyone introduced him or herself and is happy to have you. After setting up all the tools you need, adjusting the monitors and the first coffee you want to start being productive. You ask for a task and a colleague assigns a ticket to you. But now what? You may ask for documentation, take your time to browse the code, maybe even ask some questions, but you don’t really get all that far without asking even more. You slowly make your way through the code base, attach the debugger, go one step at a time and choose the wrong path from time to time – Just to start all over again. It seems like you are stuck in a maze.

This is a situation that seems to be quite common in some places. New developers joining the team are expected to just make their way somehow and find out things on their own. While every developer will likely be able to read, debug and understand code it is really hard to understand the all contexts in a code new code base.

Situations like this are really frustrating to deal with and cost a lot of energy. It might also cost your company quite some money, depending on how long it takes the new worker to get comfortable with the code and infrastructure.

Improve the situation

It is pretty simple to be honest. There are some steps that every member of the team can do:

1. Create context diagrams of your system and everything that is connected to it.

   • What are the dependencies?
   • What are the the responsibilities?

2. Create a diagram which shows how you usually structure code.

   • Are you using a common architecture pattern?
   • Are you separating different layers?

3. Write some documentation for the critical parts of your software.

   • How do I extend this part of the code?
   • What issues did you have with this piece of code already?
   • What should I definitely know if I touch this code?

4. Add comments to your code.

   • Firstly > Do NOT add comments everywhere.
   • If needed add comments to explain the WHY.
   • Interfaces should have a comment on each function and one top-level comment to explain its responsibility.

5. Use a common style for your code.

The list above just provides a few examples of what we can do to help people better understand our code base and systems. Always keep in mind that everything on the list wants to be maintained and kept up to date, so be careful so you don’t add too much additional load to your daily work.

Pair Programming

All solutions above add extra work and do not really scale that well, but there is a different approach we can take. We can sit together and write, debug and read code in pairs! Pair programming is the all-in-one solution suitable for almost every purpose.

We can pair a junior and a senior to help both of them grow – The junior will learn lessons from the senior and the senior will consolidate his knowledge and learns how to share it. We can also pair two juniors, so they can learn together. And we surely can pair two seniors as well, so they can find solutions for even the most complex problems. We might also pair testers and developers or developers and designers. The possibilities are nearly endless and all of them result in helping each other grow and learn.

We can now also skip the code review after we implemented a feature, because we already had 2 people looking at it, which will free up some additional time to pair.

Some people will try to tell you that it might slow your team down or that it costs too much. Don’t trust them – Try it out yourself. It might take some time getting used to, but you will get better every time you pair up. You will likely see an increase in development speed, code quality and a decrease in knowledge islands! :)