D'autres techniques de survie classiques
1/ Noyez les gens dans une apparente complexité. Utilisez un vocabulaire technique et des concepts abstraits face aux clients, chefs de projets.
2/ Recréer la roue pour un quelconque motif d'optimisation (qui devra paraître vital pour vous). Refusez toute forme de template ou de librairies, ils ne sont pas adaptés.
3/ Investissez vous à fond dans des sujets annexes qui ne requièrent pas le jugement d'un client, par exemple Git, la configuration de l'edi. Créez des architectures techniques et des nomenclatures complexes sur ces domaines. Restez éloignés des sources de jugement : trouvez la niche où vous serez seul.
4/ Critiquez le travail des précédants développeurs, c'est à cause de leur programme pourri si vous n'y arrivez pas. La seule bonne façon de réfléchir est la votre.
5/ Critiquez l'imprécision de la demande du client : c'est le client qui ne vous a pas dit que la sécurité, les performances et la gestion de la concurence étaient importantes, c'est de sa faute. Vous n'êtes qu'un simple exécutant.
6/ Critiquez le mauvais usage des utilisateurs : ils font n'importe quoi, c'est normal que votre programme soit planté. Les gens auraient dû suivre l'indication de la page 42 du manuel ou ce que vous aviez pensé lors du développement.
7/ Critiquez le temps qu'on vous a alloué. On vous a demandé de développez facebook en 3 jours, c'est normal que vous ayez pondu une daube inmaintenable, sans doc et qui fonctionne à moitié ; ce n'était pas votre rôle d'expert de dire non ou de definir une cible cohérente avec ce chiffrage.
(ils survivent comme ils peuvent les développeurs médiocres)
Partager