Remote Team Culture - Code Review and Style Guides
Code Review at Rietta
When joining a new team, a developer can be nervous when making their first pull request or contribution to a codebase.
The thought of your team going through your code and ripping it to shreds is both reasonable and scary. So how does a team eliminate this fear and instead, encourage newer developers to greet code reviews as a opportunity to not only improve their code, but to encourage a healthier environment to actually collaborate?
This begins with the team environment itself, removing the mindset of “I need to show this person their place on the totem pole” and replacing it with “I should teach this person everything I know so we can both grow” and as an opportunity to develop a rich relationship with your new teammates!
Reviewing code is not only a chance to share one’s experiences and knowledge, but it also is a way to open doors and break down barriers between coworkers in a team.
At Rietta we make it a point to have team member, new or old, review code of all shapes and complexity. Everyone gets the chance to learn from everyone elses problem solving skills, and to provide input and ideas from a perspective that a more experienced developer may overlook.
During our code reviews, we look to pull from our own experiences and share it with our team members. It is easy to say “because its best practice”, but it doesn’t help to explain why something is best practice.
Why is it better to use this type of ORM query over the other? Is it because batch processing is more efficient than loading all the records at once? Giving comments explaining why when making a recommendation is not only helpful for the code owner, but a learning opportunity for the reviewer as well.
Patience, empathy, and humbleness are marks of a great leader and mentor; a coworker with these qualities are invaluable to a organization. These are key qualities in a team looking to prevent a parade of developers walking through a revolving door due to a poor development environment lacking in collaborative development practices.
Coding Style Guides at Rietta
When hearing the words “Code Style Guides”, many think of standards that some person made based on their personal opinion on how code should be written for an entire team. While this method of creating a style guide may be true for some teams, here at Rietta, we work as a team to create style guides and best practices for working on our client projects, as well as internal ones.
Code styles are not decreed by one person, rather we discuss snippets of code on Slack and have input from team members new and old.
Our CEO, Frank Rietta, sometimes leads these discussions based on some code being reviewed or consulting of best practices. During these discussions we first discuss discuss and then we come to a consensus on the preferred style.
For instance, we had a discussion regarding the usage of concerns in Ruby on Rails applications.
We would first:
- Establish what the best practice or convention for
concerns. - Why is this a best practice, avoid appeal to authority, but reason it in our own words.
- Discuss “what ifs” and “gotchas” when using
concerns. - What about testing, what ways make sense in testing it? (We do a lot of testing at Rietta)
So why is it important to have this kind of open discussion, where everyone is encouraged to contribute, ask questions and understand the why?
Why even consider the opinion of a person who has been developing for a year vs someone who has been do it for 10 years? Work in a agency or product teams is not going lone wolf and delivering and fix complex problems. To have perspectives from all team members is invaluable to the growth of not only the individual, but for team cohesion.
Working in an agency setting or any setting on a development team isn’t a lone wolf exercise with no communication. It’s a team sport, where it’s important to have the perspectives of all of your team members. You and they will grow as individuals and as a team.
Team Growth and Cohesion
Everything discussed above applies to all teams, but it is especially important when working in distributed teams where face to face interactions are not a normality. Our remote team communications are mostly in the form of emails, Slack messages, and Github code reviews. While we make it an effort to video chat on a daily basis and have checkin calls from time to time, we can forget that emails, slack messages, and code reviews can lack the nuances in face to face human communication.
The benefits of spending the extra time to encourage and have human to human conversation is enormous. Discussing ideas, reviewing each others work, and collaborating on style guides can give everyone a voice which can go a long way in maintaining a motivated team.
Taking the extra steps in conveying your points in a concise but human to human way is important in maintaining a motivated team.