Développeur côté serveur

Les opérations de base, la validation, la sérialisation, l'appel d'un service par un autre, et les tests de tout cela.

Transactions, idempotence, reprises, ordre — décider ce qui ne doit jamais être vrai et s'assurer que cela ne l'est jamais.

Concevoir ce qui est stocké, et le migrer plus tard sans arrêter le service ni rien perdre.

Autorisation, frontières entre clients, ce qui fuit dans un message d'erreur, et ce qu'un point d'entrée interne expose si quelqu'un le trouve.

Les plans de requête, la mise en cache, la facture, et la requête devenue lente parce que quelque chose en amont a changé.

L'astreinte : décider sous pression du temps ce qu'il faut annuler, ce qu'il faut dégrader, et ce qu'on dit aux gens pendant que c'est encore cassé.

L'estimation interne d'Amazon sur l'ingénierie d'Amazon, publiée par l'entreprise qui vend l'outil — la partie qui fait le travail, celle qui le mesure et celle qui le vend sont la même, ce qui est dit ici parce que cela ne peut pas être vérifié de l'extérieur. L'entreprise publie aussi sa méthode : le temps économisé a été estimé à partir du nombre de dépendances Java migrées, en supposant un jour ou plus de temps de développeur par dépendance à la main. Notez ce qu'est la migration : une montée de version de langage a un compilateur et une suite de tests existante pour oracle, donc la réussite est vérifiable par machine à chaque étape — la forme la plus favorable possible pour ce genre d'automatisation, et non un résultat général sur le travail côté serveur. Et notez ce qui est affirmé et ce qui ne l'est pas : 4 500 années sont du travail non fait, par plus d'un millier de développeurs, sans aucune déclaration que l'un d'eux soit parti ou qu'un poste ait été supprimé.

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 moitié visible de ce métier — les points d'entrée et la plomberie — est la moitié exposée, et c'est ce pour quoi on vous aurait recruté. Les parties qui tiennent portent sur ce qui ne doit jamais arriver, et cela s'apprend en étant présent quand quelque chose est arrivé. Approchez une rotation d'astreinte plus tôt que cela ne paraît confortable.

Votre position est plus forte que celle de la page frontale sur la tâche la plus exposée, et la raison n'est pas que le travail soit plus dur — c'est que se tromper coûte cher et ne se voit pas, donc la responsabilité est concentrée. Guettez le mode de défaillance que cela crée : relire des modifications générées sur des systèmes où une erreur reste silencieuse pendant des mois.

Rester et se renforcer

Allez là où une erreur coûte cher

Paiements, grands livres, identité, tout ce qui a un régulateur — des domaines où une modification sans surveillance n'est pas permise, si bien que la relecture et la responsabilité sont financées plutôt que supposées.

Refaçonner le poste

Détenez la frontière que les agents peuvent franchir

Quelqu'un doit décider ce qu'une modification automatisée peut toucher dans un service où une erreur est silencieuse. Dans la plupart des équipes, personne n'a reçu cela, raison pour laquelle cela apparaît dans les revues d'incident plutôt que dans les fiches de poste.

Mouvement latéral

Passez au travail de données ou de plateforme

Le raisonnement sur la cohérence, la défaillance et le coût se transfère directement, et les deux sont des endroits où le même jugement s'applique à une surface plus large.

Les parties bougent à des vitesses différentes : un chiffre unique cacherait donc ce dont vous avez besoin. Écrire des points d'entrée est déjà largement du travail de machine. Décider ce qui ne doit jamais arriver quand deux requêtes arrivent ensemble, ou ce qu'un message d'erreur a le droit de révéler, n'a pas bougé, parce que ce sont des positions dont on répond plutôt que de la frappe. Un signal vérifiable : quand quelque chose a cassé le trimestre dernier, le plus dur a-t-il été de le trouver ou de décider quoi en faire.

Sur sa tâche la plus visible, il est moins exposé, et la raison mérite d'être comprise plutôt que prise comme un réconfort : la justesse côté serveur est souvent invisible et coûteuse à rater, donc une plus grande part du travail est de la responsabilité. C'est une différence structurelle, non un classement de difficulté, et cela peut changer — la moitié « points d'entrée » de ce métier est exposée exactement aux mêmes conditions que la moitié frontale.

Pour les entretiens, cela n'a pas changé. Pour le travail, le partage honnête est que se rappeler un algorithme compte moins qu'avant, tandis que raisonner sur la défaillance compte plus — savoir ce qu'une reprise fait à un système déjà en difficulté est la compétence même que les questions de conception cherchent à tester, appliquée à quelque chose de réel. Apprenez-la de vos propres incidents plutôt que d'une liste.

Elle peut déjà en rédiger un, et ce n'est pas la contrainte. La contrainte est que quelqu'un doit garantir ce qu'il ne doit jamais faire, migrer ses données des années plus tard sans rien perdre, et être éveillé quand il tombe. Ce sont des positions de responsabilité, et la responsabilité n'est pas devenue moins chère — dans les domaines réglementés, elle est devenue plus explicitement exigée.