Tech tips when starting a startup project

I started as a young developer at Azendoo, a French startup located in sunny Bordeaux, about 5 years ago. At that time, I was fresh out of engineering school and had just started as a front-end developer at Azendoo. After two years on the same project, and dozens of new or abandoned features, the team was struggling with the lack of consistency in our code and process 🙊

It’s one thing to code, it’s another to take a step back and try to improve how we are organized with regard to our code.

In the past year, we have focused on improving our speed on feature release, whilst ensuring that our releases had as few regressions as possible. Here is some advice I would have liked to have received when we were starting out. 😊

1. Apply solid and simple Git conventions

As your team grows, you need to clarify how to organize your repository, name branches and write commits. Instead of trying to build a custom process, pick an existing convention.

• Git Flow for our branching model and release organization.
• Git Commitizen for commit conventions.
• Azbot, a homemade CLI (Command Line Interface), to release to staging or production ( we’re working hard to replace it with Docker 💪🏻 ).

2. Use tests and a CI (Continuous Integration) as early as possible

You should write tests as soon as you start writing code. Even if you think that this small piece of code is going to be improved upon in the near future… Guess what? It won’t be. And that’s for sure. Writing high quality code won’t guarantee that it won’t break. It will do — and harder than you think.

To start with, write unit tests on your API and front-end, even if it’s just simple tests so as to reduce regressions in the future. You’ll feel a lot more confident. Then, right after that, add a continuous integration.

• Use tests to reduce regressions and write high-quality code.
• Use CI to ensure that each new piece of code change doesn’t break the existing code.

3. Learn to review code

To ensure code quality and consistency, the best approach is to have e-v-e-r-y pull-request reviewed by one or two teammates. This will have a great impact, without requiring a lot of setup effort.

• Consistency: by reading each other’s code, everyone will learn and teach the best patterns.
• Quality: by reviewing code, the team ensures that the code base is readable and clear.
• Pedagogy: new teammates or interns we will learn faster and have thoughtful discussion around code, not dogmas.

4. Be a better developer by linting your code

Setting code conventions is hard. Having to force every member of your team to follow them is even harder. That’s why using Linters with code conventions written by others is an easier approach. The whole team has to accept the conventions first, and then they just follow the rules. No more debates about the dangle comma, or spaces vs. tabs. 😊

We are using multiple tools to ensure our code grammar:

• Hound: a great online service wich reviews every pull-request on GitHub;
• Eslint: library to lint our JavaScript and React.js code (we follow Airbnb’s conventions);
• Editorconfig file: add an .editorconfig file to ensure indentation and last-line rule across your team.

5. Use a project management tool

This piece of advice might seem dead simple, but trust me when I say that many young companies forget to organize precisely their development. Having to write and organize tasks as a team gives you a lot of advantages:

• Each member in the team can see who is working on what;
• You easily communicate with the rest of the team and set deadlines;
• Prioritizing makes you more efficient and avoids not-so-useful stories.

For all our development, we use Azendoo to schedule and assign tasks. In a subject called “Development”, we have four sections: Next, Code & Test, QA & Review and Feature Flag (available only for Beta users). Every new feature, polish and sometimes bugs will follow this process.

To sum it up, here is a to-do list:

- [ ] Use a version control hosted service (Github, Gitlab etc.)
- [ ] Run continuously your tests in a CI (Codeship, Gitlab etc.)
- [ ] Set up a lint config
- [ ] Set up an editor config
- [ ] Set up a Git commit messages and branches convention
- [ ] Review every pull-request by one or two teammates
- [ ] Deploy your app ( or service ) with a one line command
- [ ] Organize development around a clear to-do list

Hope you liked these simple and basic tips. Don’t hesitate to recommend 💙 or share✌️.

Kudos to Emily Fiennes for reviewing this article 😘