Don’t Leave Anything to Chance

Software development is an art that requires harmonious collaboration among team members. Collaboration and knowledge transfers are extremely important, as they allow a team to work collectively as one mind.

Code reviews are an important practice that engage the entire team. This key industry practice helps ensure that the entire team evolves along with the code. Some teams work horizontally across databases, servers, and UI code, while other teams collaborate on different feature areas of a product. Code reviews can stimulate conversation and learning across the code base for both types of teams.

Why are code reviews valuable?

• When a single engineer owns an area of code, the responsibility for that code follows him or her outside of the office. Designating a single team member as the critical path makes the team vulnerable. Code reviews distribute knowledge among team members..
• When adding a new team member, it is vital to help them quickly integrate into the team. Code reviews stimulate organic conversations on code structure, style and architecture during the course of the workday. New team members can more efficiently and organically integrate themselves into team culture, minimizing onboarding costs.
• Code reviews are an excellent way for engineers and reviewers to discover bugs. Working through a tricky area of code demands that both parties understand the flow of logic and affirm the solution.
• No team is static. Deep investigations into a product enable the development of improved engineering paradigms. Code reviews help keep team members engaged and distribute the best practices and lessons learned across the team. Engineers are also able to connect on a more meaningful technical level, resulting in a better product. While the best bugs are the ones not coded, code reviews often reveal flaws in logic, as a new set of eyes will find things the original engineer didn’t account for.

Ultimately, we guarantee the quality of what we implement while making sure it’s a proper fit for the overall solution and environment.

We employ end-to-end testing to verify that our applications work as expected across the entire software stack and architecture, ensuring that all micro-services and components are properly integrated and work together.

We build, test, and deploy software by using unit tests, integration tests, as well as continuous integration and delivery (CI/CD).

Leveraging these best practices allows us to verify that the code is working correctly, prevent future regressions, document the code’s behaviour, provide design guidance and support refactoring.

At Nextbit, we believe deeply in the strength of open-source software. Employing an open-source approach allows for optimal flexibility and control over the solutions we develop.

We use open-source software every day. All of our projects are based on open-source languages, software and tools. We also value giving back. That’s why we work to fix upstream bugs when we find them.

We also think our work can benefit others. Information wants to be free, and ideas evolve more quickly when they are free to travel. When possible, we publish our software under open-source licenses via our Github profile.

We also strive to learn from others. Open-source code allows other developers to introduce patches and report bugs. We are eager to learn from others, and we like to receive feedback on our code.

The biggest advantage of working remotely and asynchronously is the flexibility it provides. Flexibility makes it easy to strike the difficult balance between work and personal life. Remote work allows you to plan when you do and don’t work.

However, remote work situations can mean that the majority of conversations with colleagues are exclusively about work. Therefore, everyone is encouraged to dedicate a few hours a week to social calls with teammates. We want our team members to make friends and build relationships with the people they work with in order to create a more comfortable and well-rounded workplace environment.

We also follow the following communication guidelines:

Team members should use asynchronous communication when possible. You are not expected to be available all the time. It is perfectly fine to wait until your planned working hours to respond to issues, emails and chat mentions.

Gitlab issues are preferred over email or chat. Using public instead of private channels ensures that other people can learn from the discussion.

Provide links to resources. When you refer to something (a merge request, issue, commit, webpage, comment, etc.) please include a link to the reference material.

All company data should be shareable by default. Don’t use a local text file; instead, save files on the company cloud or in a Git repository.

When you are asked to do a task, clarify how much time you will need. It is necessary to schedule an appropriate amount of time to complete a large task, and by giving the other person a deadline, you give them a chance to perhaps seek a different solution to their problem

• Documentation of knowledge
• Fewer Meetings; and if you miss one, you can watch a recording
• Everything is public, everyone can contribute
• More flexibility in daily life
• Reduced interruptions and improved productivity