Comment devenir un ingénieur logiciel -10x

**Jade Emy** · 20/02/2024, 16h21

Comment devenir un ingénieur logiciel -10x

Les ingénieurs +10x sont peut-être mythiques, mais les ingénieurs -10x existent : les secrets pour devenir un ingénieur -10x.

Pour devenir un ingénieur -10x, il suffit de gaspiller 400 heures d'ingénierie par semaine. Combiner les stratégies suivantes vous aidera aussi:

Réduire à néant la production de 10 ingénieurs. Modifier les exigences aussi loin que possible dans le développement. Pour éviter les reproches, obscurcir les exigences dès le départ.

Créer 400 heures de travail. Demandez à votre équipe d'effectuer des tâches qui ressemblent à du travail. Les exemples les plus courants sont les présentations, les diagrammes et la gestion des tickets. Créez des rituels inutiles.

Créer 400 heures d'épuisement professionnel/de rotation. Soyez ingrat. Rejeter la faute sur autrui. Semer la confusion. Se mettre en colère. Obliger les autres à faire des heures supplémentaires.

Prendre 10 ingénieurs en otage dans une discussion technique. Laisser les ingénieurs discuter de leurs idées. Les encourager à préférer l'élégance au pragmatisme. Veiller à ce que personne n'ait le pouvoir de prendre des décisions.

Ajouter 400 heures de frais généraux de communication. Les réunions détruisent les calendriers. Pour faire perdre discrètement du temps aux autres, rédigez de longs messages/documents et partagez-les aussi largement que possible. Accueillir toutes les opinions et viser l'engagement.

Gaspiller 10 semaines de salaire en coûts de cloud. Écrire des programmes lents. Éviter les index de la base de données. Exécuter des programmes à fil unique sur des machines à 16 cœurs. Opter pour du matériel exotique avec de la RAM et des GPU fantaisistes. Stocker généreusement les données sur la RAM/le disque. Ne comprimez rien. N'accordez aucune attention à la disposition des données.

Créer des outils inutiles. Décidez que les solutions existantes ne répondent pas à vos besoins. Écrire des scripts qu'une seule personne peut comprendre. Si le script fait quelque chose d'important, éviter la documentation.

Ajouter 400 heures de temps de compilation/construction. Les constructions lentes font perdre du temps et génèrent des intérêts composés. Plus les temps de construction augmentent, plus les développeurs sont susceptibles de se distraire. Pour s'assurer que les développeurs changent de contexte, la recompilation devrait prendre au moins 20 secondes. Vous pouvez également écrire des tests lents pour un effet similaire.

Écrire des tests inutiles. Créer des dépendances sur des variables particulières sans tester la fonctionnalité sous-jacente. Simuler des appels de fonction jusqu'à ce qu'aucun code original ne s'exécute. Introduire un caractère aléatoire subtil dans vos tests afin qu'ils réussissent ou échouent sans raison.

Gaspiller 400 heures d'ingénierie sur une mauvaise architecture. N'accordez aucune attention à la manière dont la conception de votre système évoluera au fil du temps. Au contraire, faites en sorte que votre équipe soit obsédée par les décisions d'architecture, de sorte qu'elle n'ait pas le temps de tester ses hypothèses.

Gaspillez 400 heures sur le déploiement. Créez autant d'environnements que possible. La production et la mise en scène doivent être très différentes. Lancez du code fragile avec des systèmes de construction fragiles. Migrer fréquemment vos bases de données.

Perdre 10 semaines de salaire à cause de clients mécontents. Échouer à plusieurs reprises dans la détection et le traitement de bogues graves. Ne pas prêter attention aux failles de sécurité.

Rédiger une documentation sans intérêt. Expliquer le code dans des messages privés. Écrire des wikis que personne n'utilise.

Piéger 10 ingénieurs dans un projet de bricolage futile. Attirer des ingénieurs brillants et gâcher leur potentiel. Sous-estimer la difficulté du projet auprès de la direction ; surestimer l'utilité du projet. Dire à la direction que le projet est "presque terminé" jusqu'à ce qu'elle le mette au rebut.

Ajouter des dépendances qui nécessitent 400 heures de maintenance. Les ingénieurs apprennent individuellement chaque bibliothèque.

Retarder le pivotement. Ne jamais admettre l'échec. Noyer votre équipe dans des coûts irrécupérables. Ignorer les compromis 80/20 qui pourraient améliorer votre situation.

Embaucher 10 ingénieurs 0x. Les coûts d'opportunité peuvent tuer. Les poids morts ne nuisent peut-être pas activement à votre équipe, mais ils occupent les chaises de personnes qui pourraient vous aider activement.

Engagez 5 ingénieurs -1x. Ne vous contentez pas de poids morts. Engagez activement des ingénieurs qui provoquent des catastrophes et résistent à l'apprentissage.

Empêchez les ingénieurs 10 -1x d'être licenciés. Ne pas faire tanguer les bateaux. Ne pas laisser de traces écrites des échecs. Se porter garant d'une mauvaise ingénierie.

Incorporer 400 heures de triage des bogues. Créer des programmes impossibles à déboguer. Plaquer des couches d'abstraction sur tout. Écrire du code spaghetti. Rendre tout sensible aux conditions initiales. Éviter les fonctions pures. Utiliser généreusement les dépendances. Dites "ça marche sur ma machine" chaque fois que c'est possible.