• Lazy Developers Are the Best Developers
    https://cacm.acm.org/blogs/blog-cacm/238155-lazy-developers-are-the-best-developers/fulltext

    Apologie de l’Eichmannisme... Scary.

    When you deal with legacy code, you often find yourself having to engage in so-called “deep thinking.” You’re expected to understand large problem scopes before you even begin trying to fix the small bugs. For a long time, this stressed me out. Then I got an idea: be lazy.

    At my company, Zerocracy, we practice a #NoAltruism policy. We, quite literally, think only about ourselves and our personal profit. This might sound a bit harsh. Isn’t it better to play nice and try to appease your clients? In an ideal world, maybe. But here’s what we’ve learned about clients: they also practice #NoAltruism.

    Un commentaire et la réponse de l’auteur :

    Mehmet Suzen
    July 21, 2019 04:04

    This is unacceptable practice from ACM’s professional ethics guidelines. Zerocracy promotes
    no-alturism and n- help. This practice violates the core mission of ACM as an organisation which is “Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.” I request ACM to retract this article. Computing professionals have obligation to behave in alturistic manner and help each other for both advancement of business productivity, human-well being and advancement of computing systems . Zerocracy is a disgraceful movement for computing profession.

    Yegor Bugayenko
    July 22, 2019 10:46

    Mehmet, can you please elaborate on how exactly “contribute to society” lead to the conclusion that we are obliged to behave in an altruistic manner?

    • Assez d’accord : je viens de remporter un contrat pour ajouter une boutique à un site et avant même de commencer, les infos transmises sont fausses, le client m’avait caché que le site est en panne à cause des mauvais choix du prestataire précédent, les maj de sécurité n’ont jamais été faites.
      Je suis assez furieuse de cette manière de vouloir me contraindre à faire un boulot de débogage massif, long et gratuit.

    • Dommage de commenter ça par un point Godwin.
      Je suis plutôt d’accord. La plupart des « décideurs » méprisent ce qu’on appelle l’opérationnel et comptent sur le fait que les développeurs (ou n’importe quelle autre autre « petite main ») en fassent un peu plus que ce qui est prévu, comme ça, pour leurs beaux yeux, parce qu’ils sont habitués à être bien servis. Il est donc important d’avoir une attitude telle que l’article le décrit. Chez moi on appelle ça le « t’as qu’à t’en foutre », ça fait vraiment du bien de le dire à voix haute quand on se prend la tête sur un problème qui n’est juste pas du tout de notre ressort. Sinon on finira comme les graphistes à courir après des concours de logos.

    • C’est quoi, un troll ?

      @najort tapes troll dans la fenêtre recherche
      de seenthis et tu verras ce qu’est un troll ou le trolling (trop-linge in french), la troll-attitude, le troll au mètre (ne pas confondre avec le trouillomètre) etc...
      Seenthis n’est pas épargné par ces malfaisants, en ce moment ça a l’air plutôt calme ou alors ailleurs que mon champ de vision de seenthis.
      Dans le passé, il y en avait un particulièrement pugnace. Carmignola 1er qui s’appelait il pratiquait le troll au mètre presque partout, tout le temps, sur n’importe quel sujet. Un vicieux, une engeance trollesque à lui tout seul. Il a fini par déclaré forfait ou plutôt seenthis a décidé de l’éjecter. https://seenthis.net/messages/666918

    • Dans le monde professionnel, on contractualise, ou on crève. Et quand on contractualise, on le fait au bon moment, ou on crève. C’est à dire qu’on se met d’accord sur le contenu de la mission, on lui donne un prix, et on valide l’ensemble par un contrat, écrit ou oral, peu importe. Si on loupe une de ces 3 étapes, on augmente les chances de créer des conflits et des frustrations.

      Alors quand je lis : « de toute façon les donneurs d’ordre croient toujours qu’on va faire ce qui n’a pas été prévu, alors maintenant, je ne fais que ce que je veux, et si je trouve que c’est pas ce qui a été prévu, je rejette la responsabilité sur les autres, les demandeurs, les prédécesseurs, la météo », ça me fout en rogne parce que ça mélange pleins de choses, et que ça ne fait finalement pas très professionnel.

      Ceci dit, contractualiser, c’est peu reposant, et ça demande en effet... de ne pas être flemmard. Ça demande d’analyser, d’argumenter, de contre-argumenter, et ce temps là, parfois, on n’a pas envie de le passer, parce qu’il n’est pas payé. Alors il faut s’arrêter, et dire que cette analyse ne peut pas être gratuite. Etc. Bref, ça demande une certaine forme de professionnalisation, ça ne s’improvise pas.

      J’ai eu à gérer des gens qui :
      – Acceptaient la mission (les tickets) en donnant un délai au pif ou en tout cas en ne remettant pas en cause les délais envisagés ;
      – Puis te disaient au bout d’un délai indéterminé que bon, c’est pas possible de le faire dans le délai parce que ceci ou cela (lire les arguments moisis qu’on voit dans le billet et ne jamais oublier que sa propre production pourra un jour être jugée par des « paresseux géniaux ») ;
      – Et te jouaient le même tour régulièrement, au point qu’aucun de leurs projets ne se terminaient dans des temps raisonnables, et que même quand ils avaient la possibilité de tout maîtriser du début, te sortaient l’argument « oué mais c’est le cahier des charges fonctionnel qui est passé à côté des vrais enjeux ».

      Exténuant.

      Et donc, #troll.

    • @biggrizzly le scénario idyllique que tu décris avec le cahier des charges bien rédigé et où le client le respecte comme il faut tout au long du projet, c’est de la perle rare ça, en tout cas pour le développement logiciel (surtout si on bosse sur le principe des méthodes agiles où intrinsèquement on prévoit des modifs en cours de projet). En vrai, tu crois avoir tout décidé en accord avec le client et dès que tu commences à bosser tu as déjà des tas de demandes/besoins qui n’ont jamais été évoqués auparavant parce que le client a « oublié » ou tout simplement pas compris qu’il pouvait y avoir un impact quelconque d’un truc pourtant évident. Et donc là tu as 2 solutions : tu fais et tu empoches la thune en y passant deux fois plus de temps que prévu ou bien tu demandes une rallonge et ça passe ou ça casse, et dans ce dernier cas à toi de voir si tu peux te payer un avocat pour récupérer la thune (qui potentiellement couvrira à peine tes frais d’avocat).
      Je suis d’accord que contractualiser et bien faire le contrat est hyper important mais ça ne fait pas tout, encore faut-il que les parties soient de bonne foi et sur un pied d’égalité.
      Et quand le client c’est la boîte dans laquelle t’es salarié je n’en parle même pas (c’est ma situation) mais disons que la phrase que j’entends le plus c’est « on voit mieux une fois que c’est fait » (avant de te demander de tout modifier).

    • Je ne décris pas un scénario idyllique. Je décris la seule solution pour survivre dans ce métier autrement qu’en se plaignant tout le temps.
      Quand le cahier des charges n’est pas assez précis, tu le fais préciser. Avant si possible. Ou en tout cas, tu te permets d’inscrire noir sur blanc les limites d’interprétation à tel ou tel point du CDC que tu souhaites fixer, afin de sécuriser ta mission et tes éventuels dépassements, et d’avoir un moyen de dire stop. C’est exténuant. Mais c’est la seule solution. Un cahier des charges n’est jamais assez précis ni convenablement rédigé. Tout comme la documentation post-développement. C’est un travail permanent. Et trop souvent, les développeurs sont laissés à la merci de chefs de projet qui s’en foutent et ne veulent pas faire ce travail de maîtrise du client.

    • C’est beau cette rhétorique capitaliste de savoir si le client est roi ou non. Cependant, l’article ne pointe pas nécessairement uniquement ce rapport là du doigt. C’est, je le répète, de l’Eichmannisme pur et dur : « fais ce qu’on te demande et ne réfléchis pas ». Le cas n’a rien de nazi cela dit, c’est la médiocrité latente qui ressort, avec ses figures et ses « point » nommés qui ont ensemble mené le monde où il est.

      Aussi, si on parle développeur.e.s, excusez du peu, mais il serait temps de se sortir les doigts du nez et de commencer à ouvrir les yeux sur la réalité du logiciel et ses implications sur la vie quotidienne. Les abus que les dynamiques de pouvoirs taylorisés entrainent sur l’humanité viennent s’insérer jusqu’au plus intime de nos habitudes et il faudrait peut être se poser des questions sur les conséquences de nos décisions et de nos actes. Sur les conséquences de vendre nos actes justement médiocre. Je t’en vendrai du Godwin, haha, ou du Troll, même combat - seul le style change.

      Finalement, dans ce lynchage ridicule, la question ne concerne plus que le potentiel à faire de l’argent, ou de ne pas en faire assez. Je ne vois pas pourquoi on se fatigue à développer.
      C’est navrant - mais crucialement intéressant de voir de nouveaux avatars pointer leur nez.

      C’est donc ça un troll. Merci Bigg et vander, haha, la journée commence pleine d’entrain !

    • Il ne s’agit pas de faire ce qu’on nous demande sans réfléchir, c’est tout le contraire même : naturellement nous sommes portés à plutôt bien faire les choses et les donneurs d’ordre en profitent trop souvent pour en tirer une plus-value plus que conséquente. J’ai donné l’exemple des graphistes qui est maintenant une profession gangrenée par le travail gratuit.
      Par ailleurs cela me désole de voir qu’Eichmann est encore considéré comme un simple exécutant.