18 mois de startup à grande vitesse

Et voilà, c'est terminé. Ce 30 mars, après 18 mois de travail acharné et 1784 commits, ma première aventure professionnelle s'achève.
Sang et sueur, fatigue et parfois dégoût mais aussi accomplissements et échanges passionnés ont étés mon lot quotidien. Le moins que je puisse dire est que j'ai énormément appris.
J'aimerais essayer de détailler les réussites et échecs de cette expérience professionnelle.
Il s'agit donc d'un article pour une relecture plus personnelle au style très décousu.

Ma situation dans l'équipe

Il y avait trois grand pôles : la direction, l'équipe de vente et l'équipe technique. J'étais le lead dev et comme mon supérieur, Max, est un pote et qu'on était deux pendant les débuts, toutes les décisions techniques ont étés prises ensemble.
Nos rôles différaient car il faisait l'interface entre la direction et les devs et je prenais plus de temps sur les points techniques. Un CTO architecte/manager et un lead dev technique : le binôme parfait.
Venant de la même école, on échangeait très rapidement avec un grand niveau de compréhension et de confiance mutuelle.

Du coup, ce duo contrastait un peu avec les autres developpeurs moins qualifiés ou moins "en phase". Toutefois, après une première mauvaise surprise dûe à une erreur de jugement en recrutement, nos coéquipiers techniques étaient efficaces et agréables.

Les échanges avec la direction étaient corrects mais le fait de devoir avancer très vite et la haute volatilité des choix d'interface m'ont fait rapidement fuir le frontend. Je me suis aperçu que j'aimais avoir un travail plus spécifié avec une stabilité plus grande que la semaine. Je me suis donc naturellement réfugié de plus en plus côté backend, jetant en pâture les devs frontend aux sables mouvants de la webapp.

Moins mon travail était compréhensible par la direction, mieux je me portais. C'est un aveu de faiblesse de ma part de ne pas avoir réussi à faire les choix techniques offrant une souplesse plus grande (je vais y revenir) mais c'est également un problème de communication entre la direction et l'équipe technique.

Les choix techniques

Je considère les choix techniques comme étant ma responsabilité majeure durant ces 18 mois. Beaucoup d'erreurs ont été faites et c'est le moment de trier le bon du mauvais.

Pour le backend, les choix ont étés très bons avec du recul. Symfony est un excellent framework PHP : solide et efficace. Beaucoup de documentation, une communauté active, une base de code mature : que du bon. Pour la prochaine API que je vais écrire (plus là dessus à venir dans un prochain article), j'utiliserai api-platform, basé sur symfony. PHP n'est pas le langage de programmation le plus élégant mais ces outils le transforment en monstre de productivité pour faire des API.

Côté base de donnée, on a bien fait de choisir du classique. On a commencé par MySQL pour passer sur MariaDB par ma volonté. Même si ce choix a été dans l'ombre de Doctrine, l'ORM de notre choix, rester classique et choisir une base de donnée relationelle nous a fait gagner en productivité. Seul bémol : le charset par défaut qui n'est pas de l'utf8 et l'utf8 qui n'en est pas. On est jamais passés à l'utf8mb4...

Autre très bon choix : Docker. Avoir un environnement de travail immutable était un plaisir sous linux. Malheureusement, ce n'était pas applicable aux autres devs qui travaillaient sous macOS ou windows. Je me suis donc retrouvé seul sur Docker. Heureusement que je m'occupais de la gestion des serveurs ! Je n'avais aucune adaptation de mon code à faire pour la production. Si vous n'utilisez pas de containers de nos jours, c'est un risque énorme de perte de temps pour la mise en production et d'instabilité.

Le shell s'est choisi tout seul comme huile de moteur pour les installations, l'interface entre le code front et le back... Pas de regrets et j'ai appris à écrire des scripts POSIX qui fonctionnent malgré la présence de bash 3.3 et de coreutils macOS truffés d'incompatibilités avec les GNU coreutils. Apprenez à écrire pour du shell standard en utilisant que le tooling de busybox et vous devriez obtenir un résultat correct.

Finalement, les mauvais choix étaient surtout côté frontend...

Le choix d'Angular n'était pas si mauvais que ça mais on commençait à sentir les limites du framework sur la fin. Trop de choses réinventées, pas assez de stabilité et une lourdeur que je n'ai pas envie de retrouver de si tôt. Le problème est surtout qu'Angular n'est pas assez mature à mon goût. Peut-être dans un an pour la v7 ou la v8 ? En tout cas, la v5 qu'on manipule ne permettait pas vraiment de faire quelque chose de solide avec l'effectif réduit qu'on avait.
On a choisit Angular en partie parce que c'est un framework complet (au contraire de react) mais il manque cruellement d'une gestion centralisée des données. On a tenté redux mais pris par le temps, on a été obligé de rebrousser chemin et ça s'est révélé la plus grosse perte de temps de ces 18 mois. Redux est très bien mais notre modèle rendait son utilisation très complexe et javascript n'est pas très facile à manipuler quand on doit rendre des modèles complexes immutables.
À la fin, je sentais qu'on avait finalement les outils pour réattaquer redux mais on avait épuisé une grande partie de notre énergie et tout le temps disponible...

Bootstrap s'est révélé être un bon choix. La v4 est vraiment meilleure que la v3. Pas grand chose à dire.

Un autre mauvais choix a été l'interface entre le front et le back. Nous n'étions pas assez agiles et je n'aimais pas REST. C'est le seul point sur lequel on a eu une incompréhension Max et moi. Au final, on a eu une communication hybride, ni REST, ni RPC, ni GraphQL; quelque chose d'horrible qui va demander du travail a être revu.
Avec redux, c'est ma deuxième grande défaite technique. Beaucoup de temps de perdu a essayer d'être trop intelligent dans des domaines que je connaissais mal.

Je ne referrai pas ces erreurs.

La suite ?

Il y a beaucoup d'autres choses à dire sur ces 18 mois mais je n'ai pas encore assez de recul pour tout analyser.
Je n'ai pas pris de vacances depuis 4 mois, travaillant souvent le weekend sur mes projets personnels. Je peux dire que c'est n'est pas possible de faire ça sur le long terme.
Je vais commencer par prendre une bonne semaine de vacances puis je pourrai réfléchir mieux.
N'habitant pas Paris, je devais prendre le train et ne pas être chez moi la moitié de la semaine. Je pense que c'est un mode de travail qui est finalement très fatiguant. Je m'en suis aperçu que quand j'ai réalisé que ça allait s'arrêter.
Je dois apprendre à mieux organiser mon temps pour ne plus avoir le sentiment permanent d'être submergé.
18 mois en plongée. Il est temps de revenir à la surface et de respirer un grand coup.