Mes règles règle de travail et peut être dev / ops

Mes propres règles de travail et peut être dev / ops . Et plus largement de salubrité dans le travail.

  • Ne pas construite sa productivité au détriment de celle des autres
  • Les personnes compétentes ont de l’empathie et sont généreuse
  • L’état de l’art n’est que ce qui est partagé et compris par la majorité
  • On ne déplace pas la merde on la nettoie
  • Utilise l’interface graphique que si tu maîtrises déjà  la ligne de commande.
  • Un carnet et un feutre seront toujours de loin les outils les plus robustes et résiliant de l’informaticien.
  • Raconter une histoire est le B.A.BA de la pédagogie technique.
  • Une bourde expliquée est toujours plus bénéfique qu’un coupable pendu.
  • Un outils n’est jamais la solution à un problème d’organisation ou de management.
  • La dictature technique est une option face à l’anarchie. Au moins Il y en à un qui décide et assume.
  • Faute de dialogue, travailler à l’oreille est une option.

Une réflexion sur “ Mes règles règle de travail et peut être dev / ops ”

  1. Travailler à l’oreille consiste (faute de retour, de dialogue, de savoir par qui ou pourquoi c’est utilisé, si c’est utile, si le ROI affiché est réel ou quand tout les interlocuteurs refuse la prise de risque ) à débrancher, supprimer, masquer, éteindre le service, la fonction ou le serveur. Si ça gueule immédiatement, tu t’excuse, tu rebranche mais tu a l’interlocuteur principale en direct et un niveau d’importance en fonction des décibels. Bon je cache pas qu’il faut pas être peureux pour la jouer à l’oreille 🙂

    Exemple
    – A tu sais le serveur dont tu demande si on peux le supprimer depuis trois mois ? et bien la pub viens de répondre, c’est bien à eux et ils l’utilisent plus.
    – Je sais, le serveur est éteins depuis trois mois

    « 

Laisser un commentaire