Les ingénieurs en logiciel ne sont pas (et ne devraient pas être) des techniciens, car un grand ingénieur en logiciel est celui qui automatise le travail répétitif ou manuel

Par Gabriella Gonzalez

Les ingénieurs en logiciel ne sont pas (et ne devraient pas être) des techniciens, car un grand ingénieur en logiciel est celui qui automatise le travail répétitif ou manuel, par Gabriella Gonzalez

Les ingénieurs logiciels ne sont pas (et ne devraient pas être) des techniciens, par Gabriella Gonzalez

Je ne pense pas que la prévisibilité soit une bonne chose dans le domaine du génie logiciel. Cela va probablement surprendre certaines personnes (en particulier les managers), mais je vais expliquer ce que je veux dire.

Selon moi, un grand ingénieur logiciel est celui qui automatise le travail répétitif/manuel. On pourrait penser qu'il s'agit là d'une barre assez basse à franchir, n'est-ce pas ? L'automatisation des tâches répétitives n'est-elle pas... comme... la programmation 101 ? La plupart des ingénieurs en informatique ne seraient-ils pas d'excellents ingénieurs selon mon critère ?

Non.

Je dirais que la plupart des grandes organisations d'ingénierie logicielle encouragent l'anti-automatisation, principalement en raison de leur penchant pour la prévisibilité, en particulier pour les estimations et le travail prévisibles. La raison en est que le travail prévisible est un travail qui aurait pu être automatisé, mais qui ne l'a pas été.

Exemple

Je vais vous donner un exemple concret de travail prévisible dans le cadre de mon dernier emploi. Au début, nous avions un développeur dédié à la maintenance de notre API web. Chaque fois qu'une autre équipe ajoutait un nouveau point d'extrémité API gRPC à un service interne, ce développeur était chargé d'exposer ces mêmes informations via une API HTTP. Il s'agissait d'un travail relativement routinier, mais qui nécessitait néanmoins du temps et de la réflexion de la part du développeur.

Au départ, les responsables ont apprécié le fait que ce développeur puisse faire des estimations fiables (parce que le travail était bien compris) et ce développeur a apprécié le fait qu'il n'avait pas à sortir de sa zone de confort. Mais ce n'était pas très bon pour l'entreprise ! Cette personne devenait souvent un goulot d'étranglement pour le lancement de nouvelles fonctionnalités parce qu'elle avait inséré son propre travail manuel comme une étape nécessaire dans le pipeline de développement. Elle a fait valoir que la direction devrait embaucher davantage de développeurs de ce type pour faire face à la demande croissante de leur travail.

Notre équipe s'est opposée à cette idée car nous avons reconnu que le travail de ce développeur était tellement prévisible qu'il pouvait être complètement automatisé. Nous avons fait valoir à la direction qu'au lieu d'embaucher une autre personne pour faire le même travail, nous devrions l'automatiser davantage et c'est une bonne chose que nous l'ayons fait ; ce développeur a rapidement quitté l'entreprise et au lieu d'embaucher pour le remplacer, nous avons automatisé son travail à sa place. Nous avons écrit du code pour générer automatiquement une API HTTP à partir de l'API gRPC correspondante (De nos jours, il existe des outils prêts à l'emploi pour faire cela, comme grpc-gateway, mais nous n'en disposions pas à l'époque) et cela a généré beaucoup plus de valeur pour l'entreprise que l'embauche d'un nouveau développeur.

Techniciens vs ingénieurs

J'aime utiliser le terme « technicien » pour décrire un développeur qui (A) fait un travail bien compris et (B) n'a pas besoin de sortir très souvent de sa zone de confort. Il n'y a évidemment pas de frontière nette entre les ingénieurs et les techniciens, mais en général, plus le travail d'un développeur est prévisible et routinier, plus il a tendance à devenir un technicien. Dans l'exemple ci-dessus, je considère que le développeur chargé de la maintenance de l'API Web est davantage un technicien qu'un ingénieur.

À l'inverse, plus une personne s'oriente vers le métier d'ingénieur, plus son travail devient imprévisible (de même que ses estimations). Si vous automatisez constamment les choses, tout le travail prévisible se tarit lentement et il ne reste plus que le travail imprévisible. La nature du travail d'un ingénieur logiciel est qu'il s'attaque à des tâches de plus en plus difficiles et ambitieuses au fur et à mesure qu'il automatise davantage.

Je pense que la plupart des entreprises technologiques ne devraient pas privilégier la prévisibilité et devraient éviter d'embaucher ou de cultiver des techniciens. La raison pour laquelle les entreprises technologiques affichent des valorisations hors normes est l'automatisation. Le fait de privilégier la prévisibilité et le travail bien compris encourage par inadvertance le travail manuel au détriment de l'automatisation. Cela n'est pas évident pour beaucoup d'entreprises technologiques car elles supposent que tout travail impliquant du code est nécessairement de l'automatisation, mais ce n'est pas toujours le cas - ou même habituellement ; je suis personnellement très cynique quant à l'efficacité de l'ingénierie de la plupart des entreprises technologiques. Les entreprises technologiques qui n'en tiennent pas compte finissent par sur-embaucher et par se demander pourquoi moins de travail est effectué par plus de personnes.

Ou, pour le dire autrement, je considère que c'est un signal d'alarme : Je considère en fait comme un signal d'alarme le fait qu'un ingénieur ou une équipe entre dans un « flux » prévisible, car cela signifie qu'il existe une opportunité prometteuse d'automatisation qu'ils sont en train d'ignorer.

Licence : This work is licensed under a Creative Commons Attribution 4.0 International License. - Ce travail est soumis à une licence Creative Commons Attribution 4.0 International License.

Source : "Software engineers are not (and should not be) technicians" (Gabriella Gonzalez)

Et vous ?

Pensez-vous que l'avis de Gabriella Gonzalez est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Huit conseils pour ceux désireux de faire long feu et donc une longue carrière en tant que développeur : un condensé de 26 ans d'expérience, par Jayme Edwards

Peut-être que la programmation ne vous rend pas malade, c'est tout ce qui vient presque nécessairement avec la programmation pour gagner sa vie

Réflexions sur l'avenir du développement de logiciels suite à l'arrivée des grands modèles de langage (LLM) capables de générer du code, par Sheshbabu Chinnakonda