12 leçons apprises comme CTO

J'ai appris quelques leçons en étant CTO de Datananas, la startup SaaS que j'ai fondée en 2014, pendant sept ans. Certaines sont venues calmement. D'autres sont arrivées avec une facture, un bug en production, ou cette petite odeur de brûlé que prennent les mauvaises décisions techniques.

1. Less is more

La loi du rasoir d'Occam appliquée au développement logiciel est simple : les implémentations les plus simples sont presque toujours les plus robustes. Il est toujours tentant de construire des systèmes complexes. C'est moins maintenable, mais cela donne parfois l'impression de participer à une civilisation avancée.

En tant que CTO, vous devez combattre la complexité. Chaque librairie ou outil ajouté est une chose de plus que votre équipe doit maîtriser. Chaque ligne de code ajoutée peut créer de nouveaux bugs, et moins de code signifie souvent moins de bugs.

N'écrivez pas non plus du code abstrait parce que vous pourriez peut-être en avoir besoin ailleurs plus tard. Écrivez seulement ce dont vous avez besoin maintenant, parce que vous ne pouvez probablement pas encore prédire tous les cas.

2. Les monorepos

Les monorepositories font gagner beaucoup de temps.

Ils peuvent ajouter un peu de complexité à votre CI/CD, mais cela vaut largement le coup pour plusieurs raisons :

• Tout le code est au même endroit, et vous pouvez intégrer des changements backend, frontend ou app dans une seule pull request.
• Il est plus facile de partager du code et de maintenir la compatibilité.
• Vous pouvez tester toute la codebase ensemble.

Même Google le fait, et pour de bonnes raisons. J'en parlerai peut-être dans un autre article.

3. Refaire from scratch

À un moment, il sera très tentant de tout jeter et de recommencer.

N'oubliez pas que si un logiciel a pris six mois à coder, il faudra au moins six mois pour le refaire, et probablement plus si vous voulez faire mieux.

La plupart des problèmes peuvent être corrigés. Cette décision doit donc être prise très sérieusement, pas un vendredi soir après trois cafés et une démo ratée.

4. Le contrôle qualité

Voici quelques pratiques à mettre en place pour maintenir un bon niveau de contrôle qualité.

• Bloquez les branches development et master pour que personne ne puisse pousser directement dessus.
• Mettez en place un linter strict pour garder un style cohérent et limiter les erreurs.
• Ajoutez de la couverture de code.
• Empêchez le merge des pull requests sans review, avec des erreurs de linter ou une baisse de couverture.
• Gardez un changelog : vous devez pouvoir savoir facilement ce qui était en production à n'importe quel moment.
• Documentez le code.

Chaque fois que vous pouvez automatiser une vérification, faites-le, par exemple dans votre pipeline CI/CD.

5. Les peer reviews

Chaque changement dans le code devrait être relu.

En tant que CTO, vous devriez relire toutes les pull requests jusqu'à ce que vous ayez trop de développeurs.

À ce moment-là, vous pouvez déléguer une partie des reviews à des leads, simplement parce que vous n'aurez plus le temps de tout gérer. Avant cela, cela doit rester une priorité absolue.

6. Pas de spec, pas de code

Aucun code ne devrait être écrit sans un minimum de planification. Tous les développeurs devraient passer du temps à rédiger les spécifications techniques de l'implémentation prévue.

Vous devez relire et valider cela avec eux. Si le projet est gros, découpez-le en plusieurs parties et relisez-les au fur et à mesure. Vous ne voulez pas découvrir après un mois de travail que l'implémentation est mauvaise. C'est exactement le genre de surprise dont personne n'a besoin, sauf peut-être les consultants en audit.

7. Embauchez moins

Plus de développeurs ne signifie pas plus de vitesse, parce que recruter ajoute de la complexité. Je préfère avoir un très bon développeur dans mon équipe plutôt que quatre développeurs moyens.

Soyez particulièrement prudent avec les stagiaires et les profils juniors.

8. Comment mener les entretiens

Comme CTO de startup, vous pourriez passer tout votre temps en entretiens. C'est très chronophage.

Il faut construire un processus qui vous évite de passer des heures avec chaque candidat.

Ce que je faisais souvent : poser des questions techniques dans l'esprit de Joel Spolsky pour évaluer très vite le niveau du candidat. Si vous voyez qu'il ne correspond pas aux attentes, terminez l'entretien, même après dix minutes, en expliquant pourquoi et en donnant des pistes pour progresser.

9. Soignez les conditions de travail

Les développeurs ont besoin de calme. Personne ne devrait être autorisé à les interrompre. Si vous avez besoin de quelque chose, utilisez Slack.

Il est prouvé qu'après une interruption, un développeur a besoin d'au moins quinze minutes pour retrouver sa concentration.

Offrez-leur Spotify. Pour 10 dollars par mois, c'est un très bon investissement.

Si le calme n'est pas possible au bureau, autorisez le remote work. J'étais un peu réticent au début, mais si vous avez de bons développeurs et que vous relisez leur travail, tout ira bien. Et si vous n'êtes pas aussi sexy ou financé que d'autres startups, cela peut devenir un vrai avantage pour recruter.

10. Les tests

Si vous avez construit un MVP, vous n'avez peut-être pas écrit de tests. Ce n'est pas forcément un problème, parce qu'il ne faut pas passer trop de temps à tester un logiciel qui n'a pas encore atteint le Product-Market Fit et qui sera peut-être jeté. Écrire des tests prend facilement deux fois plus de temps.

En revanche, si vous n'avez pas de tests automatiques, compensez avec du test manuel. Vous devriez avoir quelqu'un pour tester votre produit plus tôt que vous ne le pensez. Ne sous-estimez pas la puissance du test manuel.

Quand le produit grandit, il faut écrire des tests, parce que les testeurs ne peuvent pas tout retester tout le temps. Cela vous aidera aussi à éviter de casser les fonctionnalités centrales. Chaque fois que vous corrigez un bug, ajoutez un test.

Le graal est d'avoir des tests end-to-end avec de vraies données sur tout le logiciel, mais cela prend beaucoup de temps à mettre en place. En attendant, testez manuellement les gros changements avec une liste écrite des fonctionnalités à vérifier.

Je dirais grossièrement :

1. MVP ou pré-revenu : tout tester manuellement.
2. Dès que vous avez du revenu : écrire des tests unitaires et continuer les tests manuels.
3. Au-delà de 15k de MRR : investir du temps dans les tests end-to-end.

11. Garder les priorités dans le bon ordre

Les priorités devraient toujours être :

1. Corriger les bugs.
2. Relire le code.
3. Écrire du nouveau code.

Vous remarquerez que les choses les plus importantes sont souvent les moins amusantes. La nature a un humour douteux.

Beaucoup d'équipes commencent par écrire de nouvelles fonctionnalités, puis relisent le code des autres, puis corrigent les bugs quand il n'y a plus rien d'autre à faire. Or dans une startup, il y a toujours de nouvelles fonctionnalités à écrire.

12. La communication

Il est très important de communiquer avec le reste de l'entreprise.

Les autres équipes doivent savoir ce qui est en développement et quand les choses sont mises en production.

Je tenais un changelog et je le publiais dans Slack à chaque mise en production.