A few tips for growing together with your new developer

Every once in awhile a new employee comes along. You want to give him/her the best training you can, but you also want it to be quick and painless, while getting them up and running, ASAP.
At Bizzabo, we decided to review how we train new developers and improve our methodologies.

We wanted to improve how we teach new developers in Bizzabo. A new junior developer recently joined our team and I thought it would be a good time to review our methodologies on how to share our knowledge with the trainee. One thing for sure, we all agree that we have plenty of room for improvement. As a former flight instructor, I took some guidelines and techniques from my background in the aviation world so we can improve the way we develop our developers. Our work culture encourages us to use a Bizza-prefix for every word we want, so we call our senior developer the bizzateacher, the new employee bizzastudent, and we’ll even call fun in-office videos make bizzavideos. And yeah, so maybe we’re a bit odd :).

The training program lasts for a month. The trainee receives their own Trello board to manage her/his training tasks. The trainee is in charge of setting up her/his schedule and meetings with bizzaboers from other departments (product, sales, marketing, customer success, etc.).

1. Why did you do this? If you don’t remember go over it one more time and make sure you know why.
2. How did you test it?

• Did you run our automation test? Did you add one?
• Did you run the unit testing? Did you add one?
• If you change something Did you check that it didn’t break anything?

     3.  Write up to 3 things that we learned from the code review in Github.

If our trainees hear those 3 things for every code review, it will become second nature to their coding skills and develop into their process even when flying solo.

Some more insights:

Each Bizzastudent will have a Bizzateacher that will be in charge of his/her training. We are working in a squad formation, the senior developer of the squad the Bizzastudent joined will usually act as Bizzateacher. The Bizzastudent should not switch between Bizzateachers while working on the same feature as it can sometimes get confusing. For example, one teacher may want the trainee to use underscore, the other with plain JS. One teacher will solve the issue with handlebars and the other with jQuery. The best course of action will be: one teacher for each feature. (It also rhymes quite well…)

The code to production will be production ready no matter what. Even if the teacher has many remarks to tell the trainee. As said before, we write only 3 remarks in our code review, as an individual can’t handle 20 remarks in one code review, it won’t make her/him a better coder.

Also, it’s good practice to not have Bizzateachers contradict each other, even if sometimes you think you have a better solution to a code that is already ready for production and was already reviewed by another Bizzateacher. This helps streamline the onboarding process while avoiding confusion for the Bizzastudent.

This is an ongoing process so before starting another code review the teacher should go over the last 3 remarks that the trainee wrote in her/his last code review. Make sure that the trainee improved at least one of those remarks in the current code review you are just starting.

After 2-3 months the new hired developer can start code reviewing as well. It will take a little more time until s/he can be a Bizzateacher.

We are starting this project for the first time with our awesome new developer. Let’s see how it goes…