11 Oct 2021

First step when landing in a team

Thomas Riboulet

Lead consultant

Software engineering and building products are relying heavily on communication. One big part of communication within software is actually at the code level : how the code is written. Ensuring the whole team shares the same vocabulary is a very important step within any team.

That’s why when joining a team we should go through a couple of checks around how the code looks, how the team is sharing the basic bricks they use on a day to day basis.

The code looks : it’s important

Code style is important, not because it’s either right or wrong, but because having a single style shared by the team just remove a lot of extra fluff in reviews and exchanges.

There is no need to have someone in charge of the style and nitpicking every single code review on just quotes and spaces. There are applications for that ! Every language now has great linting and syntax checking tools. Ruby has Rubocop/https://rubocop.org with a great set of defaults and ways to configure most parts of the syntax.

How to pick a syntax is generally easy : there are a few popular ones out there, pick one, set it up and go with it.

An alternative is to use a project called Ruby Standard

The aftermath

Just like any other things, that’s not the end though. There will be code to update and issues with the coding style at some point. That’s great, because you should have setup time to have the team talk about this kind of issues on a regular basis. If not then it might be a first topic to bring up to create a team retrospective.

Beyond the look

Is that just how far we can go though ? Well, style guides are great to give a basis for the team, but code templates for services or specific bricks are also a great way to give the team a base to start from.

In a very similar way as style guides this is meant to alleviate the debates that might come up within the engineering team :

  • What language do we use ?
  • What set of base libraries or framework do we use ?
  • What are we using to handle background jobs ?
  • How are we documenting the APIs exposed ?
  • How are we running dependencies locally ?
  • And more

This might not be the job of the CTO, it’s usually the job of the most senior leads in the team and the CTO might be the judge on the final choice.

This can be done through a simple document, through a code repository, or a mix of both. Again, it’s not meant to be set in stone. This should evolve with time, through retrospectives and findings.

And with that ?

A lot of you will have the experience to go with those ideas, hit the road and run with it. Those should be among the first steps you go through with your [new] team. They are great ways to cut through debate, start anew and build up new rituals and communication paths.

Yet, remember you can also count on your peers to discuss how to put such steps in motion and how to go through them. You can also contact us to discuss how to implement such an approach and how it could help.

A RubyOnRails consultancy based in the EU, we build your applications and services all over the world !



© 2021. All rights reserved.