Développeur frontal

Prendre une maquette ou une description et produire le balisage, les styles et la structure de composants qui l'affichent.

Vide, en chargement, partiel, hors ligne, en erreur, lent, et celui où l'utilisateur a appuyé deux fois sur le bouton — décider ce que chacun doit faire et le réaliser.

Le vieux téléphone, la connexion lente, le navigateur en retard de deux versions, le lecteur d'écran, le paquet devenu trop gros.

Parcours au clavier, sémantique pour les lecteurs d'écran, contraste, ordre du focus — et, de plus en plus, pouvoir démontrer que vous l'avez fait.

La bibliothèque partagée : décider ce qui y appartient, ce qu'un changement casse, et qui doit en être averti.

Réponses en flux, incertitude, citations, boutons d'arrêt, et ce que l'écran fait quand le modèle se trompe ou est lent.

La base de code d'une entreprise, publiée par cette entreprise, l'estimation de migration à la main (1.5 année de temps d'ingénierie) étant fournie par la même entreprise et non vérifiable de l'extérieur. Ce qui rend le résultat reproductible est le mécanisme, que le billet décrit en entier : la migration est une machine à états dont chaque étape a un arbitre automatique — jest, eslint et tsc disent réussi ou échoué — de sorte que le modèle pouvait réessayer sans personne pour regarder, et la première passe en masse a traité 75 % des fichiers en quatre heures. La queue restante est le chiffre le plus utile : après quatre jours de réglages, 97 % ; les derniers 3 % avaient chacun été relancés entre 50 et 100 fois et ont été finis à la main. Le billet dit aussi explicitement que le principal facteur était la sélection des bons fichiers connexes à mettre dans le prompt — qui a grossi jusqu'à 40 000 à 100 000 jetons en tirant jusqu'à 50 fichiers — plutôt que la formulation du prompt. Il ne rapporte aucun changement d'effectifs, de recrutement ou de postes, et n'en prétend aucun.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

La tâche pour laquelle on vous aurait recruté d'abord — transformer une maquette en écran — est la plus exposée ici. Cela vaut d'être su avant de passer un an à devenir rapide dessus. Les parties qui tiennent sont les états que personne n'a dessinés et l'obligation que cela marche pour tout le monde, et ni l'une ni l'autre ne s'apprend en construisant des pages de portfolio.

Votre levier est passé de produire des écrans à les contraindre : le système de design, les états, le budget de performance, l'obligation d'accessibilité. C'est un travail moins visible et plus difficile à montrer dans un portfolio, ce qui est un vrai problème au prochain changement de poste — commencez à consigner ce que vous avez refusé et pourquoi.

Rester et se renforcer

Détenez la couche de contraintes

Quand les écrans deviennent bon marché, la denrée rare est la personne qui maintient la cohérence d'un produit — la bibliothèque de composants, les états, le budget de performance.

Refaçonner le poste

Devenez celui qui peut prouver l'accessibilité

Cela passe de bonne pratique à obligation sur plusieurs marchés, et une obligation a besoin d'une personne nommée capable de démontrer la conformité plutôt que de l'affirmer.

Mouvement latéral

Allez vers la décision produit

Les développeurs frontaux voient ce que les utilisateurs font réellement plus directement que presque quiconque, et cette observation est la matière première du travail produit.

Aucun chiffre ne serait honnête ici, et la question se pose mieux tâche par tâche. Produire un écran depuis une maquette est déjà largement fait par machine ; décider ce que l'écran fait quand la donnée manque non, et répondre du fait que cela fonctionne pour quelqu'un qui utilise un lecteur d'écran non plus. Un signal vérifiable par vous : quelle part de votre dernier mois a été passée à taper du balisage par rapport à décider des comportements. Si c'est surtout le premier, l'exposition est réelle et le mouvement va vers le second.

Sur sa tâche la plus visible, oui, et la raison est mécanique plutôt qu'un jugement sur la difficulté : l'entrée est visuelle, la sortie est du texte, la justesse se vérifie à l'oeil, et les données d'entraînement sont le web public. Mais l'essentiel d'une vraie base de code frontale n'est pas cette tâche — ce sont les états que personne n'a dessinés, les appareils sur lesquels personne n'a testé, et les contraintes qui maintiennent la cohérence d'un produit qui grandit. Une exposition sur la moitié visible n'est pas une exposition sur le métier.

L'étendue n'est pas automatiquement une protection, et c'est le cadrage à abandonner. Deux expositions superficielles sont plus faciles à remplacer qu'une profonde ; ce qui protège est d'être la personne à qui l'on peut faire confiance pour juger, et le jugement est propre à un domaine. Si vous traversez, traversez pour une raison — les états et le modèle de données sont réellement liés, et comprendre les deux vous rend meilleur à la frontière, là où vivent la plupart des bogues.

On le demande encore, et c'est un signal qui s'affaiblit pour la même raison que la première tâche de cette page : un relecteur sait désormais ce que coûte la production d'un bel écran. Ce qui ne s'est pas affaibli est la preuve d'un jugement — un composant que vous avez supprimé et pourquoi, un état que vous avez traité et que personne n'avait spécifié, un budget de performance que vous avez tenu sous la pression. Cela est plus difficile à rassembler et beaucoup plus difficile à générer.