Êtes-vous ingénieur, développeur ou programmeur ?

Voyons rapidement la différence entre les trois métiers et ce qu'on attend réellement des gens qui les pratiquent.

Note : Dans la suite de cet article, j’ai choisi d’utiliser les mots ingénieure, développeuse et programmeuse au féminin, parce que la langue française n’a pas de forme neutre et que je voulais changer un peu par rapport aux articles en général sur le sujet. Pour autant, tout est applicable quel que soit le genre de la personne. Puisque nous travaillons en anglais, nous nous posons beaucoup moins la question en interne.

Connaissez-vous la différence entre une ingénieure, une développeuse et une programmeuse ?

Pro-tip : ça marche aussi avec les codeuses, les dev, les eng, les swe, les ingés, les informaticiennes, les software et les codeuses.

(À ceci près que les développeuses ont un sens de la fête un peu particulier.)

Aujourd’hui, j’aimerais mettre ma casquette de CTO et parler de la façon dont nous envisageons le rôle de ces personnes au sein d’alan.

D’abord et pour faciliter la lecture de la suite : chez alan, on appelle ces personnes ingénieures (ou eng, pour software engineer). Ça peut froisser quelques oreilles, mais on considère que même si elles n’ont pas fait une école d’ingénieure, c’est un travail qui demande les capacités qu’on attend d’une ingénieure :

On a tendance à considérer le rôle de l’ingénieure comme étant assez large. Voici donc quelques aspects qui nous tiennent à coeur et que nous valorisons.

Une ingénieure n’est pas là pour seulement implémenter des solutions décidées par d’autres. En règle générale, l’ingénieure est partenaire de la designer dans ce qu’on appelle le « framing », où on décide de ce qu’on va construire.

Une fois ce « framing » fait, l’ingénieure a la main sur le « making » - la réalisation - et notamment le choix du comment et des technologies.

Car nous avons une forte notion de responsabilité et d’autonomie : les ingénieures, à tous niveaux de séniorité, sont censées définir leur propre sprint pour la semaine, en coordination avec les personnes de leur équipe. La plupart de leur temps doit être alloué aux projets qui touchent aux objectifs de leur équipe.

L’ingénieure n’est pas une exécutante et pourra prendre des décisions qui permettent d’améliorer le produit : autant que sa connaissance technique qui lui permet de savoir ce qui est faisable ou non, on attend d'elle un recul sur son travail.

Il est nécessaire que l’ingénieure soit motrice sur les questions produit.

Chez Alan, on a fait le choix d’avoir tout le monde comme étant full-stack : pas d’équipe frontend séparée d’une équipe backend. Ça permet d’éviter le cas de l’ingénieure backend qui attend l’autre équipe pour faire un bouton dans le frontend. Et au final d’aller plus vite !

En réalité, nous avons plutôt des « spécialistes qui se déguisent en généralistes. » Je m’explique : chaque personne a sa ou ses spécialités, et va pouvoir en apprendre aux autres. On essaiera au mieux d’aligner la préférence avec l’intérêt de l’entreprise. Il est toutefois nécessaire d’avoir la mentalité d’un généraliste, pour être ouvert sur l’apprentissage de nouvelles technologies et méthodes.

Chaque ingénieure est responsable des systèmes qu’elle construit. Ça veut dire que certains sont responsables de beaucoup de pièces de code. Quand cette maintenance prend plus de ~30% du temps de la personne, c’est un signe que l’on doit passer la responsabilité à d’autres.

En général, on trouvera quelqu’un de plus junior, qui doit maintenir moins de choses, et on organisera une passation. Cela permet de garder une owner unique, tout en répartissant mieux les tâches.

Les ingénieures chez alan laissent le code qu’elles ont touché dans un meilleur état que celui dans lequel il était. Ça veut dire qu’on refactorise le code au fur et à mesure.

On n’alloue pas du temps spécifique à la refactorisation, il est compris dans le temps de développement. On ne crée pas non plus de tâche strictement pour refactorer du code : s’il n’y a pas d’impact business (soit un impact utilisateur majeur, soit dans la vitesse de développement), on garde notre pragmatisme et on laisse fonctionner.

Pas de personnes assignées au QA chez Alan ! On attend de chaque ingénieure qu’elle s’assure qu’il n’y ait pas de bug dans le code qui sera mis en production.

Ça augmente légèrement la probabilité que des bugs puissent se glisser sur le site, mais ça permet que chacun soit responsable de livrer du code de qualité.

Si un problème se déclare à cause de son code, on ne blâme pas, mais l’ingénieure se trouvera en première ligne pour aider à résoudre le problème, quitte à revert son code !

Si par hasard cette description se recoupe avec la façon dont vous aimez ou aimeriez travailler, n’hésitez pas à faire un tour du côté de nos offres d’emploi : on serait ravis de vous rencontrer.