Développeur frontal — tâches, une par une

Transformer une maquette en interface qui fonctionne

C'est la tâche la plus exposée de l'ingénierie logicielle, pour une raison mécanique : l'entrée est visuelle, la sortie est du texte, la justesse est immédiatement vérifiable à l'oeil, et les données d'entraînement sont le web public. Les outils qui génèrent un écran depuis une image ou une phrase ont atteint une qualité utilisable avant ceux qui génèrent un service côté serveur.

Un écran qui s'affiche n'est pas un écran qui part en production. Cela ne dit rien de la maintenabilité du résultat, de sa conformité à un système de design existant, ni de son comportement dans les états que personne n'a dessinés — vide, en chargement, en erreur, à moitié de liste.

Les états que personne n'a dessinés

La génération travaille depuis le chemin heureux parce que c'est ce qu'une maquette contient. Les autres états sont là où vit l'essentiel du code réel, et décider ce que chacun doit faire est un jugement produit sur ce produit précis plutôt qu'un motif à retrouver.

C'est un jugement sur l'endroit où se loge le travail, non une mesure de celui-ci. Les équipes ne comptent pas quelle part de leur code frontal relève du traitement des cas limites : il n'existe donc aucun chiffre auquel confronter cela, et l'équilibre diffère énormément entre une page marketing et un écran de salle de marché.

Faire que cela survive à de vrais appareils et réseaux

Les outils mesurent et suggèrent ici mieux que les personnes — budgets, audits et profilage sont exactement le genre de vérification mécanique où le logiciel est bon. Ce qu'ils ne peuvent pas faire est décider quel compromis accepter, parce que cela dépend de qui sont réellement vos utilisateurs, un fait sur l'entreprise et non sur le code.

Rien ici ne dit combien d'heures cela prend ni si les équipes le font — une grande part du travail frontal livré ne reçoit jamais cette attention, et l'existence des outils ne veut pas dire qu'ils ont été lancés.

Faire que cela marche pour tout le monde, parce que c'est exigé

Les vérificateurs automatiques attrapent une minorité des vraies défaillances d'accessibilité et ne peuvent pas juger si un parcours est utilisable par quelqu'un qui ne voit pas. Cette tâche est aussi celle qui passe de bonne pratique à obligation légale sur plusieurs marchés, ce qui change qui en répond plutôt que sa difficulté.

La direction repose ici sur la forme de l'exigence et non sur un résultat mesuré ; ce qui la trancherait, c'est une action de sanction nommant une interface précise et ce qui n'allait pas dans celle-ci. Les exigences diffèrent selon le marché et selon que le produit s'adresse ou non au grand public.

Détenir les composants que tous les autres utilisent

Une génération bon marché rend cela plus porteur, non moins : quand n'importe qui peut produire un écran en quelques minutes, ce qui maintient la cohérence d'un produit est la couche de contraintes, et quelqu'un doit la tenir. Le travail est du refus et du versionnement plutôt que de la création.

Que ce soit un poste ou une tâche en plus dépend entièrement de la taille de l'équipe, et le nombre d'équipes qui y affectent quelqu'un délibérément, personne ne le compte.

Construire des interfaces pour des choses qui répondent

C'est un travail qui n'existait pas avant que les fonctions génératives n'entrent dans les produits, et il n'a aucun motif établi — chaque équipe invente actuellement comment montrer qu'une réponse pourrait être fausse. Cela retombe sur le frontal parce que c'est une question sur ce que l'utilisateur voit, non sur ce que le modèle fait.

Un travail nouveau qui apparaît n'est pas un effectif nouveau : cela est absorbé par des postes existants, et rien ici ne dit que quelqu'un a été recruté pour le faire.