Cela fait longtemps que je n’avais pas écrit. Si je reprends aujourd’hui le chemin de l’écriture, cela ne sera pas pour vous parler de « geekeries » ou autres « nerderies » en tout genre. Dans ce très long billet de blog, je vais aborder le difficile sujet d’une espèce en voie d’extinction : les vieux software crafters autodidactes dont je fais partie. Je vais donc vous parler des vieux techos à travers moi, de l’évolution du marché ces 25 dernières années, du burn-out qui m’est arrivé et de la remise en question qui s’ensuit.
Je fais partie d'une espèce menacée d'extinction
Bonne lecture !
# et si c'était ... l'évolution ?
Posté par octane . Évalué à 10.
j'ai entendu un autre dino raconter un peu la même histoire. Il parlait du temps ou les informaticiens étaient aussi électroniciens et où les bugs se corrigeaient au fer à souder sur une carte mère. Il conspuait les jeunes avec leurs truc modernes (unix) qui ne savait pas gérer la RAM (la blague de l'époque, c'est EMACS == Eight Meg And Constantly Swapping, oui, 8 megas de ram semblait un horizon lointain et on était salé des softs lourdingues qui bouffaient tous ces nombreux megas…).
Aujourd'hui, on rale contre les jeunes qui hésitent pas à lancer une infra dans un cloud avec 128Go de RAM. Et si c'était pas un peu la même chose?
J'ai lu une histoire qui concernait un applicatif de Bdd. A l'époque, une appli ramait terrible. On convoque l'expert (le vieux, le barbu, celui qui sait). Il passe 3 mois dessus. Il donne un rapport. Il explique très clairement que les requêtes ne sont pas optimisées, que le serveur a 512Mo de RAM, mais que les requêtes peuvent manger jusqu'à 700Mo/800Mo de RAM (d'où swap, d'où IO en cascade, d'où lenteurs, etc..). Il explique avoir repris tout le code, et que désormais les requêtes tournent mieux, et qu'il a réussi à baisser la conso de RAM à 256Mo!!! Tout le monde le félicite. Un random peon qui passe par là pose cette question: "on a passé 3 mois du salaire d'un expert pour amélio le truc. Pourquoi on a pas acheté une barrette de RAM de 512Mo supplémentaire pour passer à 1Go ça aurait pas réglé les problèmes pareils?".
En fait, j'ai pas vraiment de réponse à tes questions (burn out, jeunesse qui s'en branle, vieux techos barbu, évolution du marché), c'est p'tet juste comme tu dis l'évolution qui passe.
[^] # Re: et si c'était ... l'évolution ?
Posté par fearan . Évalué à 10.
Ouaip et de fil en aiguille, 6 mois après faut encore rajouter de la ram, puis les requêtes mettent de plus en plus de temps à s'exécuter, alors on change le proc, puis encore la ram…
Aujourd'hui on s'en fout on déporte tout dans le nuage, si c'est pas assez (ram ou puissance, on paye une upgrade), plutôt que de se poser la question si c'est normal, y a 2 ans j'ai modifié le post-traitement d'un calcul qui mettait plus de 60s à s'exécuter, ça faisait des années que le truc était lent et qu'on disait au client que c'était normal, qu'il fallait upgrader les serveurs…
Au final, 5 minute d'investigation, j'ai trouvé où on perdait le temps, 5 minutes d'analyse, validé que le calcul devait être sorti de la boucle, 5 minutes de test + compil, et 1/2 journée d'intégration et le calcul qui faisait plus de 60 secondes se retrouvait a 2-3 secondes.
C'est l'exemple le plus marquant en proportion, mais toujours dans la même veine, j'ai passé des calculs de 45 minutes à 15 minutes, et d'autre corrections du genre.
Alors oui travailier avec des machine d'il y a 10 ans, avec peu de ram c'est un peu dommage, mais au moins lorsque l'utilisateur de plain de lenteur, on voit tout de suite de quoi il parle :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: et si c'était ... l'évolution ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Puis comme dans le journal on finit par s'apercevoir qu'on a oublié de paramétrer correctement une ligne de conf.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: et si c'était ... l'évolution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'ai vu aussi un système optimisé pour faire une simulation en 6s qui tirait ~700 000 lignes d'une base de donné. Pour faire ça, ce n'était avec des machines d'il y a 10 ans, et c'était fortement optimisé.
"La première sécurité est la liberté"
[^] # Re: et si c'était ... l'évolution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Aujourd'hui, tu as une nouvelle réponse magique : "Cela fait moins de CO2 !"
"La première sécurité est la liberté"
[^] # Re: et si c'était ... l'évolution ?
Posté par Big Pete . Évalué à 10.
C'est ça et ça existe un peu dans tout les métiers technique. Par exemple, dans la mécanique, je connais quelques vieux gourou qui ne jure que par les machines datant des années 70 et conspue les tas de ferrailles moderne bourrés d'electronique.
On pourrait tenter une généralisation en disant qu'un domaine technique évolue du stade de sa découverte avec l'aire des pionniers au stade post-industriel de son abandon en passant par plusieurs stade dont celui que je qualifierai de l'artisanat. Ce stade démarre après celui de la recherche quand la techno commence à infuser auprés des ingénieurs mais avant d'atteindre le stade industriel ou l'ingénieur perds la main au profit des logiques commerciale et de production massive.
Le stade artisanal, c'est l'age d'or pour les ingénieurs, il n'interesse plus les chercheurs, et pas encore les business man et ce sont donc eux qui pilote l'innovation dans le domaine.
Le stade du déclin peut redevenir intéressant pour l'ingénieur ou le technicien qui s'interesse a l'histoire. Même si il n'y a plus d'innovation, c'est un retour aux sources, ou l'on trouve des amateurs de belles choses, de machines improbable. typiquement, la marine a voile classique, ou la reconstruction médievale façon Guédelon, la restauration de véhicules anciens.
Dans l'informatique, ça commence à exister, mais nul doute qu'il y a de l'avenir pour les dinos dans le domaine. Il est fondamental de conserver une mémoire technologique. Aucune techno ne devrait être oubliée au pretexte qu'elle est obsolète. Il n'est pas rare qu'un principe utilisé dans une ancienne technique, serve dans une nouvelle, et avoir un retour d'expérience est toujours utile.
Par contre, c'est fondamentalement une remise en question personnelle. Garder un musée, c'est moins valorisant que jouer les petits genies innovateurs. Mais si on a du talent, on peu rester néanmoins une personne appréciée, surtout si on évite le piége de l'aigreur en envoyant paître les jeunes qui n'y comprennent rien et en s'enfermant dans un passé desormais révolu. Il faut savoir transmettre avec enthousiame ses connaissances et mettre en valeur ce que l'on appris durant ces longues années. Par contre, l'univers des grandes corpo industrielle est plutôt toxique pour le viel ingénieur artisant même si je pense qu'il peux exister des exceptions.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: et si c'était ... l'évolution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
On peut aussi se consacrer au résultat. Le but est de faire un système qui marche pour ses utilisateurs. Cela peut être très gratifiant.
Ne pas oublier que le mieux est l'ennemi du bien.
"La première sécurité est la liberté"
[^] # Re: et si c'était ... l'évolution ?
Posté par Firwen (site web personnel) . Évalué à 4.
'L’ingénieure logiciel est le développement logiciel intégré sur le temps'… Titus Winter
Une citation on ne peut plus vrai.
Se concentrer sur les résultats oui, se concentrer uniquement sur les résultats en négligeant tout le reste et comment on arrive à ses résultats: non.
C'est le meilleur moyen de créer des logiciels feu-de-paille in-maintenable qui s'écrouleront sous leur complexité aussi rapidement qu'ils sont apparus.
Il y a un juste milieu pour tout en ingénieurie, comme partout.
[^] # Re: et si c'était ... l'évolution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il n'y a pas de cause à effet entre ce que je dis et le feu de paille.
La méthode Larache ne marche pas à moyen terme, donc tu fais de la merde aussi pour les utilisateurs.
"La première sécurité est la liberté"
[^] # Re: et si c'était ... l'évolution ?
Posté par Big Pete . Évalué à 9.
Le probléme, c'est que l'on entend par "utilisateur". Dans mon boulot actuel, l'utilisateur c'est surtout celui qui paye et en l'occurence, c'est souvent des agences de pubs et in-fine leur clients derrieres. Et c'est pas du tout l'internaute. Et de mon point de vue, c'est tout un écosystéme qui est rendu toxique par ce modéle économique foireux.
Ils en ont rien a cirer que ce soit fait à l'arrache du moment que c'est pas cher que ça permet de bombarder l'internaute de pub, et accessoirement de siphonner ses données pour alimenter leur data lake.
J'attend avec impatience depuis 20 ans que le véritable utilisateur se reveille enfin, tel Néo dans la Matrice et envoie chier tout ça, et c'est pas faute d'essayer de le sensibiliser, mais il ne faut surtout pas devoir reflechir voire apprendre à utiliser internet ou un ordinateur, ça doit marcher tout seul et être gratuit….
En même temps, comme je mange grace à ces conneries, je devrais plutôt fermer ma gueule ou me mettre raccord avec mes convictions et être le premier à envoyer péter le systéme.
On y a cru : http://www.uzine.net/article60.html mais on a perdu, peut-être qu'on s'est pas assez battu…surement même.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: et si c'était ... l'évolution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Un des facteurs de motivation dans la vie est l'intérêt pour la communauté de son travail.
Franchement, si ton secteur d'activité ne te correspond pas, va voir ailleurs. Il cherche partout des dev web expérimenté. (enfin, cherchait "avant")
"La première sécurité est la liberté"
[^] # Re: et si c'était ... l'évolution ?
Posté par Big Pete . Évalué à 10.
Disons que j'ai une histoire un peu particuliére, j'ai déja grillé une cartouche. J'ai commencé a bosser dans la marine marchande, et fait mon Che Guevara en envoyer chier ma compagnie, me suis fait griller dans le métier et je me suis retrouvé plus bas que terre, puis j'ai changé de vie en exploitant mes compétence en informatique. Aujourd'hui je suis debout et je compte bien le rester, mais j'ai un regard de misanthrope sur le monde. Faut pas trop me demander d'aimer mon prochain, et moi-même par la même occasion. C'est peut-être moche, mais c'est comme ça.
Du coup, non, j'irais pas voir ailleurs, j'ai fait le tour du monde et il est pas beau a voir. L'herbe est toujours plus verte ailleurs, mais c'est juste une illusion. Je ne fuirai plus. Aujourd'hui, je suis plus en mode profite avant que ça parte définitivement en couille. Et, sincèrement, je suis le premier a en être désolé.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: et si c'était ... l'évolution ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Changer de boulot, ce n'est pas fuir.
"La première sécurité est la liberté"
[^] # Re: et si c'était ... l'évolution ?
Posté par Firwen (site web personnel) . Évalué à 4.
Pas forcement, et c'est là tout le problème. Principalement à cause d'un point que tu mentionnes plus tard, la dette technique.
Tu peux très bien avoir un résultat satisfaisant pour tes utilisateurs, mais qui en pratique est un gros tas de code pas versionné, in-maintenable, qui a besoin de 100x de ressources que nécessaires pour fonctionner.
Ça sera financièrement désastreux, humainement horrible pour ta team mais tu auras tes "résultats". Ton management sera content, il pourront rajouter une petite check "ok" sur leur objectifs "OKr" ou similaire.
C'est tout à fait compatible.
En ingénierie, tout a un coup. Et le "comment" tu arrives à un résultat compte tout autant que le résultat lui même.
Le "comment" ayant également une dimension temporelle.
[^] # Re: et si c'était ... l'évolution ?
Posté par freem . Évalué à 2.
Et a quel moment le patron est-il censé s'intéresser à l'équipe au juste?
[^] # Re: et si c'était ... l'évolution ?
Posté par raum_schiff . Évalué à 3.
Je suis d'accord que donner un cadre historique à ces évolutions est pertinent.
Quant au côté inéluctable de la chose (même si il est plus présent dans les domaines complexes comme l'informatique), qui tend à faire une analogie avec la théorie Darwinienne de l'évolution je pense que c'est forcer un peu le trait ("Espèce menacée d'extinction").
Et c'est là que le filage de la métaphore Jurasic-Park s'arrête.
Contrairement à l'évolution des organismes, l'environnement qui conditionne la "survie" d'une technique est modifiable par ceux qui l'utilisent.
(Eg : Les trilobites ne pouvaient rien faire pour contrer les conditions de l'extinction du Permien)
C'est donc une question de choix d'environnement, et celui des "grandes corpos" comme tu les cite est effectivement toxique dans ce cas.
[^] # Re: et si c'était ... l'évolution ?
Posté par Julien Jorge (site web personnel) . Évalué à 10.
J'ai déjà entendu cette histoire et… bof. Elle sous entend que la réponse à un problème est d'augmenter les ressources sans chercher, mais je ne vois pas en quoi c'est plus malin ou plus économique que de trouver la cause du problème.
C'est sûr qu'on a l'impression d'avoir perdu de l'argent avec ce fameux expert, mais bon il faut bien quelqu'un pour trouver la cause du problème. Après que la solution soit d'ajouter de la RAM ou de réduire la conso mémoire, ça se discute. Le problème c'est que si ce gars n'était pas là quelqu'un d'autre aurait augmenté les ressources au hasard en espérant contourner le problème. Plus de CPU ! plus de RAM ! plus de serveurs ! Ça va bien finir par passer… Cette augmentation de ressources ça se paye aussi sur la durée, et ça ajoute de l'incompréhension pour ceux qui entrent dans le projet par la suite.
Enfin je dis ça, à la base je ne suis déjà pas fan de l'idée d'ajouter toujours plus de puissance. Déjà parce qu'en terme de satisfaction personnelle je préfère chercher la cause du problème, et ensuite parce que, d'une manière générale, je crois que la surconsommation de ressources cause des problèmes plus grands sur le long terme. La survie c'est principalement de l'endurance, pas que du sprint, même en informatique. T'imagine un peu si on appliquait la même méthode en dehors de l'informatique, à mettre toujours plus de puissance au lieu d'économiser ? On cramerait toute nos ressources.
Attend une minute…
[^] # Re: et si c'était ... l'évolution ?
Posté par claudex . Évalué à 7.
Je pense que tout le monde généralise un cas qu'il a en tête mais je pense qu'il y a des cas différents: il y a la fuite mémoire qui va te faire ajouter de la ram tous les mois/sermaines, il y a la jointure sql sur une table qui ne bouge pas beacoup et pour laquelle on peut borner la limite maximum de ram, il y a l'erreur de config…
Du coup, la solution n'est pas forcément la même. Perso, si la conso de ram est bornée, je réfléchirais si la solution n'apporte pas plus de complexité par rapport à juste augmenter la ram.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: et si c'était ... l'évolution ?
Posté par fearan . Évalué à 4.
Meuh non une crontab qui relance l'appli à 2H et des poussière fait très bien l'affaire… Ou Quand un fix temporaire devient permanent… Et qu'on bataille dur pour corriger réellement le soucis…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: et si c'était ... l'évolution ?
Posté par octane . Évalué à 5.
Exactement. On peut aimer la solution technique qui limite la conso de RAM, sans changer le matos, avec des "belles" requêtes optimisées, etc..
On peut aussi aimer la solution pratique: on achète une barrette (coût très très faible), et l'applicatif fonctionne instantanément mieux (n'oubliez pas que pendant la durée de mission de l'expert, 3mois! les gens bossaient avec une appli qui rame).
Qui sait si la solution optimisée n'est pas bloquante, du genre: depuis que l'expert est passé réparer le bouzin, on ose plus toucher à rien ou modifier la moindre requête car ça risque de tout faire péter -> applicatif figé -> il ne bouge ni n'évolue -> applicatif promis à mort rapide.
Et l'ajout de RAM est rapide, solutionne tout, permet aux dev de continuer de modifier/manipuler les données, et permet sans doute une évolution en taille/capacité de traitement…
(bon je me fais vraiment l'avocat du diable, c'est juste pour dire qu'il n'y a pas de solution unique, surtout dans un cas hypothétique comme celui que j'ai lu dans un forum random y'a longtemps)
[^] # Re: et si c'était ... l'évolution ?
Posté par barmic 🦦 . Évalué à 5.
C'est TELLEMENT VRAI ! Chacun prends son expérience et la présente comme un fait général. Par exemple ici on lit que :
(mon dieu… c'est une seule phrase…)
C'est un cas particulier, que j'ai rencontré (à peu près), mais c'est loin de la norme de ce que j'ai rencontré dans ma vie hors c'est présenté comme une vérité générale.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: et si c'était ... l'évolution ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 5.
C'est un "cas d'école". On ne parle pas des trains qui arrivent à l'heure (les jours où il n'y a pas de grèves).
[^] # Re: et si c'était ... l'évolution ?
Posté par ✅ ffx . Évalué à 7. Dernière modification le 21 juillet 2020 à 15:07.
En pratique il faut évidemment faire les deux :
ajouter de la RAM prend peu de temps et permet d'assurer les performances voulues, car cela n'a pas de sens de continuer à utiliser un programme de manière dégradée quand une solution rapide et peu chère existe.
en parallèle, chercher l'origine du problème pour éviter d'avoir à continuellement ajouter de la RAM.
[^] # Re: et si c'était ... l'évolution ?
Posté par barmic 🦦 . Évalué à 6.
Le problème ce n'est pas les 2 requêtes SQL qu'il faut corriger, mais le fait de ne pas prendre en compte les ressources dans le développement. Sinon dans un an tu aura le même problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: et si c'était ... l'évolution ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 10.
En théorie (c'était comme ça avant en pratique aussi), les "ingénieurs de production" s'assurent que ça "tourne bien" et sont capables de réagir avant que le problème ne soit bloquant.
En pratique, les décideurs pressés ont sous traité la gestion de la production à un tiers qui lui même a sous traité à d'autres tiers, qui sont payés "au ticket", on a pas pris l'option "ingénieur de production", ni l'option "qui parle français", c'étaut trop cher, donc on traite maintenant ce genre de cas lors d'une scéance de "gestion de problème" qui aboutit à un "quick fix" qui consiste à ajouter un barrette de RAM à 100€, un correctif moyen terme qui nécessite la venue d'un expert, une procédure sur 3 semaines avec tests de non regression pour "poser un index sur la base" pour 8000 € #truestory, sachant qu'il est prévu au plan de migrer cette application sur un service SaaS chez Amazon l'année prochaine (ou celle d'après - #longterme) parce que c'est la magie du cloud et la marotte du directeur des opérations (coût prévu 50 000 €, mais c'est le métier qui le prend dans son budget alors le DSI ferme sa gueule).
[^] # Re: et si c'était ... l'évolution ?
Posté par Anonyme . Évalué à 10.
marrant ton commentaire est cité plus haut, j'ai cru être dans une faile spatio temporel :)
[^] # Re: et si c'était ... l'évolution ?
Posté par needs . Évalué à 1.
C'est un bug dans la fabrique d'espace-temps, rajoute de l'espace et ton problème est réglé.
[^] # Re: et si c'était ... l'évolution ?
Posté par flan (site web personnel) . Évalué à 2.
Bin ça dépend du problème et de ce que tu veux optimiser réellement.
La solution au problème, une fois ce dernier correctement posé, sera certainement unique (soit on optimise, soit on augmente les ressources).
Mais la solution dépendra bien sûr des contraintes et de l'objectif cherché.
Personnellement, je suis pour la bonne solution, que je détermine une fois le problème posé. Parfois ça passe par l'optimisation, parfois par l'augmentation des ressources, parfois on donne une chance à l'optimisation.
[^] # Re: et si c'était ... l'évolution ?
Posté par Firwen (site web personnel) . Évalué à 3.
Il y a rien "d'évolution" là dedans. L’ingénierie est et a toujours été une manière de compromis.
Comment arriver à un but donnée en prenant un minium de resources : Physique, humaine et temporelle.
Si upgrader ta RAM est la solution la plus rapide et moins chère, court et long terme alors oui c'est la solution.
Si diminuer ta consommation de RAM multiplié par tes 200 serveurs et les 5 ans d'exploitation de ton programme justifie tes 2j de boulot, alors oui c'est la bonne chose à faire.
C'est pas plus compliqué que ça.
[^] # Re: et si c'était ... l'évolution ?
Posté par passant·e . Évalué à 6.
Chef, faudra prévoir un bracelet antistatique avec la commande de RAM, ça va passer?
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: et si c'était ... l'évolution ?
Posté par n6p7 . Évalué à 3.
En attendant notre tour, quand on pourra râler sur nos (petits) enfants qui dansent sur leur qubits, alors que tout de même, l'algèbre de Bool c'était mieux avant …
# Tu n'es pas seul
Posté par Philippe F (site web personnel) . Évalué à 6.
Et oui, tu t'en doutes en postant ici, tu n'es pas le seul à traverser ce type de crise. Il me vient plusieurs commentaires:
Sur le burn-out qui ne dit pas vraiment son nom: je recommande de se faire accompagner en psycho-thérapie. Ça m'a vraiment beaucoup aidé personnellement (après 9 mois d'arrêt maladie). C'est normal que le médecin ne t'aie pas demandé ton avis: c'est une des caractéristiques du burn-out, tu ne peux pas t'arrêter tout seul. L'arrêt doit être décidé par l'extérieur.
Sur le gâchis de ressources et l'absence de compétence qui constitue une partie de l'informatique moderne, on en est beaucoup là. Si tu rajoutes en plus comme moi des convictions écolo, le cloud est vraiment difficile à avaler. En ce qui me concerne, j'ai trouvé un métier dans une industrie qui reste très technologique et minimaliste: la carte à puce. Ça permet de continuer à exercer son talent d'artisan du code car c'est un environnement limité et spécifique. Même si l'essentiel du temps, on fait passer nos batteries de 100 000 tests sur un delta minimaliste d'un produit stable, on arrive encore à faire un peu de job créatif…
[^] # Re: Tu n'es pas seul
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à 2.
Salut Philippe,
Je ne suis pas psy, mais je crois que ce qu'Olivier vit/a vécu, ce n'est pas un burn-out mais plutôt une dépression.
Les symptômes du burn-out sont assez différent si j'ai bien compris : on n'avance plus du tout, vraiment. Impossible de sortir de son lit physiquement. Et, toujours si j'ai bien compris, ça dure plusieurs mois.
Pour le reste, et même si c'est une dépression et pas un burn-out au sens médical, c'est bien de se faire accompagner par un psy (psychologue, psychothérapeute, psychanalyste, psychiatre : à chacun de trouver le professionnel de santé qui lui va)
PS : le psy qui m'accompagne, à la sortie du confinement et devant mes questions me confirmait que le plus dur, c'est le déconfinement. Il a beaucoup plus de travail depuis le 11 mai !!!
[^] # Re: Tu n'es pas seul
Posté par Liorel . Évalué à 7.
C'est une assez bonne description de la dépression ;)
Blague à part, la distinction burnout/dépression est âprement débattue, même par les experts. La symptomatologie est très proche, et les causes de burnout sont différentes selon les auteurs : certains vont mettre en avant la masse de travail quand d'autres vont privilégier d'autres facteurs liés au travail : injonctions contradictoires, collaborateurs toxiques…
On peut considérer en première approximation que le burnout est un cas particulier de dépression causé par l'environnement professionnel (alors que l'une des caractéristiques de la dépression est son absence de cause évidente comme un deuil, etc.), mais on commence de plus en plus à parler de burnouts non professionnels (burnout parental par exemple).
Au final, plus que de galérer sur des noms, on réfléchit surtout à mettre en place un traitement. Mais même là, ce n'est pas forcément facile. Parfois, l'arrêt de travail va être salutaire, mais parfois, c'est juste reculer pour mieux sauter : quid de la reprise du travail ? Le traitement n'est pas uniforme. De plus, le burnout n'est pas reconnu comme maladie professionnelle, et celui qui a la compétence juridique pour délivrer l'arrêt de travail (le médecin) n'est pas nécessairement le plus compétent scientifiquement (ce serait plutôt le travail du psy).
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Tu n'es pas seul
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 9.
Le problème c'est de trouver un vrai psy, pas un psychanalyste, pas un psy orienté psychanalyse et, en France, c'est pas gagné.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Tu n'es pas seul
Posté par _kaos_ . Évalué à 5.
Salut,
Ou trouver d'autres solutions.
A un moment où je me suis trouvé très mal, n'importe quel psy aurait pu faire ce qu'il voulait. J'étais fermé. Plus rien à déclarer.
C'est une practicienne de l'art-thérapie qui m'a sauvé.
C'est complètement con, mais quand t'as plus rien à déclarer, exploser un tas de glaise, ou mettre de la peinture dans une feuille, fermer puis rouvrir…
D'un coup tu te dis qu'en fait, si. Il y a des choses à déclarer.
Matricule 23415
[^] # Re: Tu n'es pas seul
Posté par igor . Évalué à 1.
Salut
Clairement plein de voies sont navigables vers la guérison.
Et quelque soit nos ages, on a le droit de renaître !
Plein de force et de discernement !
[^] # Re: Tu n'es pas seul
Posté par _kaos_ . Évalué à 2.
Salut,
Tout à fait, chacun sa voie.
Mais j'ai trouvé l'art-thérapie très utile au final. Même si je crois que ce n'est toujours absolument pas reconnu au niveau médical (pas remboursé quoi), ça peut aider. Si on veut bien s'y plier. Évidemment il faut être un peu volontaire de son côté aussi.
Matricule 23415
[^] # Re: Tu n'es pas seul
Posté par Philippe F (site web personnel) . Évalué à 7.
Il est possible de faire un burn-out de quelques semaines (c'est un début de burn-out). Soit c'est une bonne nouvelle, à savoir que l'organisme dit stop avant que le mal ne soit trop engagé: on peut donc se remettre assez vite. Soit c'est une mauvaise nouvelle, on reprend la routine d'avant alors que le problème de fond n'est pas résolu et il a toutes les chances de resurgir.
Pour la distinction burn-out/dépression, dans mon cas personnel, la cause est un burn-out mais le résultat a été une dépression dont j'ai mis deux ans à me défaire. J'ai eu la chance d'avoir des RH humains. J'ai donc pu reprendre le travail en mi-temps thérapeutique sur des projets moins stressants.
Un mot sur les solutions: en ce qui me concerne, soutien d'un psyhothérapeute + anti-dépresseur léger, puis réflexion de fond sur notre rythme de vie et nos besoins rééls. Au final, on a changé de région, changé de style de vie (vive la campagne!) et j'ai changé de boulot pour qqch de moins exigeant et là, ça va bien.
En tout cas, la perte de sens du travail est un mal très répandu autour de moi. Et les solutions sont plutôt radicales pour ceux que je vois (en gros, changement de vie). Et aucune ne regrette le confort financier d'avant!
# centre de cout...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
« il faut arrêter de déconner les gars, ce sont les développeurs le centre de coût, ils ne rapportent pas d’argent et nous coûtent cher. » - Manager
C'est très français ça. Au USA, ils font la différence entre les "makers" et les "selers". L'un ne va pas sans l'autre. Mais ce ne sont pas les sellers qui ont le plus gros salaires.
"La première sécurité est la liberté"
[^] # Re: centre de cout...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Dans un bouquin, il disait que le code legacy était celui qui n'avait pas de teste unitaire (et donc qui est très difficile à toucher)
"La première sécurité est la liberté"
[^] # Re: centre de cout...
Posté par Meku (site web personnel) . Évalué à 2. Dernière modification le 21 juillet 2020 à 16:44.
Working Effectively with Legacy Code de Michael Feathers
Cette définition doit aussi se retrouver dans d'autres ouvrages maintenant.
[^] # Re: centre de cout...
Posté par Marco . Évalué à 10.
Dans la même veine, à la SNCF, la maintenance est considéré comme un coût qui ne rapporte pas.
Les commerciaux sont vus comme ceux qui rapportent l'argent des billets de trains. Faudra leur expliquer ce que coûte un train en panne en terme d'image et de nombre de billets à rembourser ;).
Mon frère a les mêmes problèmes dans sa boite : on arrête d'entretenir un équipement, un an plus tard, tout s'est bien passé on lui dit "ah bah tu vois on avait raison on a fait des économies", deux ans plus tard, tout commence à tomber en panne, mais trop tard pour faire un entretien des équipements.
[^] # Re: centre de cout...
Posté par martoni (site web personnel, Mastodon) . Évalué à 7.
;)
J'ai plus qu'une balle
[^] # Re: centre de cout...
Posté par sebas . Évalué à 10.
En nimage, ça donne :
[^] # Re: centre de cout...
Posté par tisaac (Mastodon) . Évalué à 9.
Au moins, on est d'accord avec un peu de nuances sur ce qu'est un sysadmin :-)
Surtout, ne pas tout prendre au sérieux !
[^] # Re: centre de cout...
Posté par vv222 . Évalué à 10.
En fait c’est un peu exagéré pour l’effet comique : un sysadmin n’est pas vraiment capable d’arrêter des balles par la force de sa volonté avant d’avoir quelques années d’expérience.
[^] # Re: centre de cout...
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1.
Très décevant !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: centre de cout...
Posté par Christophe B. (site web personnel) . Évalué à 6.
Cela vient vite … car quand les chefs de projets, les devs et autres techos ne comprennent plus rien … qui on appelle ?
Après cela devient vite une habitude … on va au plus court … tout les problèmes deviennent "système" ou alors on déguise la question d'origine avec des
1 - tu peu vérifier le système ?
2 - tu peu vérifier la base de données ?
3 - tu peu vérifier les indexes ?
même si dans le cas de
1- juste un poste sur 200 a un message d'erreur
2- la base répond à 12000 requetes par secondes en ce moment
3- il fut un temps … au siècle dernier … ou les indexes pouvaient être vérolé mais ça c'était avant :)
et j'en ai plein d'autres … TROP souvent quand personne ne comprend pas … c'est un problème système
Et je vous parle pas des problèmes de performance …
[^] # Re: centre de cout...
Posté par ckyl . Évalué à 4.
Pourquoi ne pas faire bénéficier les autres de ton expérience en outillant les autres pour qu'ils puissent devenir autonome / ne plus jouer à la patate chaude ?
Développer l'observabilité d'un système est super intéressant et utile. Tu transformes ton rôle de vieux-con-ronchonchon-qui-sait-tout en quelqu'un qui transforme des années d'XP en outils, pratiques et conseils pour les autres.
Repenser son travail comme une équipe / fonction de support qui vise à permettre aux autres de travailler de manière autonome plutôt que comme l'expert qui fait est souvent une piste intéressante pour soi et pour les autres. J'ai vu beaucoup d'admin expérimentés avoir du mal avec ça. Je pense en partie pour des raisons de mentalité et en partie par ce que ça ne demande pas exactement les mêmes compétences.
[^] # Re: centre de cout...
Posté par tisaac (Mastodon) . Évalué à 1. Dernière modification le 21 juillet 2020 à 17:33.
Les autres sont aussi rigolos :-D
Surtout, ne pas tout prendre au sérieux !
[^] # Re: centre de cout...
Posté par Anonyme . Évalué à 6.
j'aurais une question, comment vous faite pour stocker toute ces image puis les ressortir au bon moment.
je la connaissait, mais flemme de chercher et aucune chance de la retrouver après des années de flou de mêmoire. Vous avez une base de donnée ?
[^] # Re: centre de cout...
Posté par Jeanuel (site web personnel) . Évalué à 6.
Utilisé la force, jeune padawa
[^] # Re: centre de cout...
Posté par fearan . Évalué à 4.
en fait oui; en plus y a même des moteurs de recherche dessus ;) Le plus dur étant de retrouver les mots clé qui servent d'index; par exemple, pour cet occurrence "developper seen by", on remarquera que cela donne aussi d'autres résultats plus ou moins proches :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Mélange
Posté par alkino . Évalué à 6.
Ne mélange t'on pas plusieurs choses ?
On fait de plus en plus du haut niveau, simplifié pour l'utilisateur. Et je pense que c'est une bonne chose.
Ce n'est pas non plus une raison pour que les informaticiens du bas niveau perdent leurs connaissances.
On a besoin des deux.
Je travaille dans ce qu'on appelle le "Middleware" et j'ai vu des entreprises où le besoin client (qui n'est pour nous qu'un autre développeur) n'était pas du tout entendu. On se paluchait sur des libs bas niveau (entendre C++) trop bien qui recodaient le standard mais en mieux !
Et derrière le client se demandait bien comment il allait utiliser notre truc qui au final ne servait pas à grand chose. On avait beau lui promettre qu'un jour grâce à nos briques de base, on allait lui fournir le meilleur framework du monde, il n'en voyait jamais la couleur.
Moi j'aime bien les trucs bas niveaux bien fait, performant et tout, mais souvent je pense que ce n'est pas pour ça que je suis payé.
De l'autre côté le client débrouillard va importer ses propres frameworks existants et se passer totalement de nous avec des trucs nouveaux tout le temps et à la fin y'a plus d'espace disque sur la solution.
Bref, c'est un peu confus, mais faut savoir trouver un juste milieu.
[^] # Re: Mélange
Posté par Big Pete . Évalué à 10.
C'est ce que disent tout ceux qui bossent dans le middleware ;-)
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
# Déformation professionnelle
Posté par groumf . Évalué à 3. Dernière modification le 21 juillet 2020 à 12:34.
Les développeurs cherchent à résoudre tous les problèmes du code … et par extension inconsciente ceux de la planète et de l'humanité.
Oui, la matrice terrienne ne peut supporter que 8,58 milliards d'êtres humains, comme on s'en rapproche ceux qui sont un peu sentients s'en rendent compte. Il faudrait plus de ressources matérielles pour en supporter davantage. Comme on ne peut pas vivre dans les nuages, la seule solution est de réduire la surface et la mobilité de ces objets pensants, on peut ainsi doubler la capacité d'hébergement terrien et éviter l'extinction.
[^] # Re: Déformation professionnelle
Posté par fearan . Évalué à 6.
Bien sur que si, on a même des variantes purement virtuelles, on en a même 3 bien connus: et certains sont représenté justement sur des nuages, le second aurait plusieurs niveaux, et le troisième j'ai cru comprendre que c'était une solution transitoire en attente de procédure de choix pour l'accès à l'un des deux autres.
Mais il y'en a d'autre, les fournisseurs sons variés, parfois le nombre de place est limité; et des fois on a même un cadeau de bienvenue !!!
J'hésite pourtant à encourager les gens à migrer volontairement au plus vite, car cela restreint l'accès à certains d'entre eux, mais puisque la seule personne documenté à en être revenu y est reparti, c'est que ça doit être vraiment bien.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Déformation professionnelle
Posté par groumf . Évalué à 1.
Ouais mais tu ne peux pas résoudre tous les problèmes du monde en un One-Shot, c'était ça l'erreur.
[^] # Re: Déformation professionnelle
Posté par fearan . Évalué à 10.
Ah pardon, l'admin sys s'y est repris à plusieurs fois avant d'envoyer son fiston (ou clone je sais pas trop, vu que c'est son fils, mais c'est lui… c'est compliqué) à deux reprises.
Le problème c'est que même après le bug originel, il a envoyé le tout en prod avant de le corriger; fatalement ça a merdé, on a du perdre beaucoup des donnée, effacée par les autres, l'affaire A&C si je me souviens bien.
Il a bien tenté un hard reboot, un gros wipe de toutes les données; avec formatage et tout et tout, il devait penser que c'était un problème de conf j'imagine; c'est un certain N. qui était en charge du dossier.
Puis comme les users une fois qu'ils s'étaient réapproprié l'espace disponible continuaient de foutre le bordel, il a envoyé de nouveau presta pour donner les CGU; une dizaine, pas trop long, mais comme il n'avait pas pris soin d'embaucher des juriste, il y'a une certaine latitude sur leur interprétation.
Enfin on arrive justement au point sus-cité, comme tu vois le patch à chaud, c'est pas évident. Y a des problème de conf hérité des précédents, y a des users qui refusent de migrer vers la nouvelle version, et qui prétendent que c'est pas une vrai version.
Cette version là à un avantage par rapport à la précédente c'est qu'elle est sensé se patcher toute seul, y a un délégué et un conseil pour ça, ça à fait plein d'histoire encore avec des rois qui voulaient intégré un patch que le délégué ne voulait pas, donc il a forké de son coté, mais c'est loin d'être le seul à l'avoir fait, C,K et L, ont aussi fait leur fork,
Y a aussi eu un gros fork en 600 et des poussières, un presta est venu avec d'autres directives, là encore des users ont préféré rester sur l'ancienne version refusant, à tord ou à raison, de croire que c'était bien l'admins sys qui l'envoyait.
bref c'est pas un one shot, y'a eu de multiples tentatives, mais je crois que le dev a vraiment merdé à la base ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Déformation professionnelle
Posté par groumf . Évalué à 3.
Nan le one shot c'était pour dire que le process fils c'était sacrifié pour absoudre les bugs/features de tous les autres.
# Il fallait le faire
Posté par AncalagonTotof . Évalué à 1.
Je ne reviendrais pas sur tel ou tel détail technique, ou pour dire que j’ai été ou que je suis dans une situation similaire.
J’espère que ça t’as fait du bien d’écrire ton histoire. Je pense qui oui, pour aussi l’avoir fait, même si seulement une ou deux personnes l’on lut.
Bon courage à nous, les vieux de la vieille !
Espérons qu’il y aura un effet C/C++ comme il y a (eu ?) un effet COBOL !
[^] # Re: Il fallait le faire
Posté par ponceto (site web personnel) . Évalué à 2.
Cela m'a effectivement fait du bien de partager cela. Ce billet ne prétend pas donner d'analyses ou de vérités absolues (et c'est dommage que certaines personnes le prenne dans ce sens), ce ne sont que des ressentis très personnels, et il faut les aborder comme tel. Sinon, bien plus d'une ou deux personnes l'ont lu, et cela a engendré pas mal d'échanges intéressants …
[^] # Re: Il fallait le faire
Posté par barmic 🦦 . Évalué à 1.
J'ai vu un présent de vérité général tout le long. Mettre le doigt sur le fait qu'il s'agisse d'un ressenti plutôt qu'une vérité me semble beaucoup aider à éviter les dépressions. Il s'agit d'un conseil et non d'une critique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Il fallait le faire
Posté par Anonyme . Évalué à 3.
heu sur linuxfr, ce serait dans les 2k personne plutot
# Been there, done that
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 10.
Tu mets le doigt sur un certain nombre de problème qui finissent par user. On a fait tourner ton billet sur la tribune et le constat est partagé, on a tous subi le même genre de conneries, quelque soit nos postes.
Comme disait Albert Camus, l'homme révolté, c'est celui qui dit : "Non !". Autour de toi, la plupart des gens de ton age a fait le même constat mais ils s'en accommodent surtout si la soupe est bonne et qu'ils ont abdiqué (avec de bonnes raisons). Le plus frustrant, c'est que la plupart des problèmes évoqués ont des solutions, mais il manque en général une "prise de conscience" au bon niveau hiérarchique, et le plus souvent cette prise de conscience est simplement impossible, car les décisionnaires ne sont pas équipés pour intégrer les causes des problèmes et/ou ils ont de bonnes raisons pour ne pas appliquer les préconisations des "sachants" (hou, le vilain mot).
Ta révolte finit par s'intérioriser, et tu as plusieurs options.
En gros, soit tu craques (burn out, bore out, dépression, etc.), soit tu te barres. Dans notre tranche d'age, je connais beaucoup de gens qui sont partis "faire autre chose" (de l'enseignement à l'élevage de chèvres, en passant par la menuiserie et la viticulture), et sur le plan global, c'est un formidable "gâchis" (enfin, ni pour les élèves, ni pour les chèvres), car on manque de sachants dans les entreprises, et on a trop de décideurs pressés.
Le plus important à noter, c'est que tu n'es pas tout seul, tu peux toujours venir partager ton analyse grâce à ton blog, par twitter ou autre RS, et bien sur ici, et aussi que certains commencent à partager un "playbook" qui donnent des pistes pour "hacker le système" …
[^] # Re: Been there, done that
Posté par pasBill pasGates . Évalué à 4.
Ah mais faut venir aux Etats-Unis (pour le boulot, uniquement pour le boulot je precise !)
Ici ils traitent les ingénieurs de pointe comme des rois, il y a des projets super intéressants, …
Bon ensuite, faut se coltiner Trump pendant 4 ans, mais bon, rien n'est gratuit, et en plus c'est un peu comme la TV realité en continu, il y a toujours un truc dingue qui se produit, on ne se lasse pas !
[^] # Re: Been there, done that
Posté par Firwen (site web personnel) . Évalué à 10.
Ou en Suisse
Ou en Scandinavie
Ou en Allemagne
Ou en Irlande
Ou au Canada
Ou au Japon
Ou dans un peut prés tous les pays qui n'ont pas du management à la Française qui constitue à externaliser tout au moindre cout en passant par des boites de presta aux qualités plus que douteuses.
[^] # Re: Been there, done that
Posté par pasBill pasGates . Évalué à 2.
La Suisse je sais pas, il y a Google à Zurich mais à part cela, les ingénieurs sont encore pas mal vu comme en dessous des managers de ce que mes proches me disent.
En fait, même en France ça va, tant que la boite est Americaine-Canadienne, c'est une question de culture d'entreprise il me semble.
# ayait on va se faire bouffer!
Posté par romi . Évalué à 4.
dans la même veine (au sens large) je lisais ce matin:
L’État automatisé : le risque d’une crise de légitimité ?
je suis aussi vieux mais pas barbu, j'ai aussi commencé à coder dans les années 80 sur une TI57 pour commencer puis sur un ZX81 en langage machine, puis électronique, puis… Linux…
ça fait maintenant une dizaine d'années que j'ai peur qu'on ne délègue trop aux machines, et surtout de la plus mauvaise des manières, pour faire du fric et de la rentabilité…
et j'ai vraiment peur que ça nous échappe, que ça nous pète à la gueule!
[^] # Re: ayait on va se faire bouffer!
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 8.
J'ai une histoire rigolote avec la DGFiP, il faudra que j'en poste un de ces quatre matins. Le danger immédiat, c'est que certains envoient nos données personnelles n'importe où, et plus précisèment dans les nuages romuliens. Il ne faut pas attribuer au machiavélisme ce qui s'explique par de la simple incompétence, mais l'inverse est vrai aussi. Visiblement, ça n'inquiéte que les libristes barbus.
# Victime
Posté par barmic 🦦 . Évalué à 5.
Je n'ai pas tout lu, mais je vais m'arrêter là dessus. C'est quoi ce marché dont tu parle ? Tu tiens un discours très victimisant. Si c'est un ressenti que tu as je le comprends, mais il est intéressant de questionner ce genre de sentiment. D'où est-ce que ça vient ? C'est quoi ce marché qui dirait que le C ou C++ sont archaïques ? Si, comme tu semble le montrer, tu l'a pris pour toi c'est vraiment important de ce demander de quoi il est question : des collègues qui se moquent de ces langages ? Le nombre de poste à pourvoir ?…
C'est important parce que se créer un ennemi fumeux et se placer en tant que victime de ce dernier ça n'aide pas du tout à bien vivre les choses. Pour le coup rationaliser un peu les choses permet de remettre les pieds sur terre et de « le marché considère mon langage comme vieux » à « dans certains contexte mon langage est remplacé par bidule » (par exemple) et donc de faire le choix changer de langage, changer de milieu ou autre.
J'ai déjà vu beaucoup de monde adopter cette démarche de victimisation et c'est vraiment dommageable pour elles. Il faut garder la tête froide et analyser ton ressenti avec un peu de recul et plus de rationalité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Victime
Posté par barmic 🦦 . Évalué à 5.
Faut pas déconner non plus. Utiliser le terme de paupérisation pour les développeurs c'est ne pas avoir conscience de ce qu'est être pauvre. Je te propose de tester ton salaire sur l'outil de l'observatoire des inégalités. C'est peut être désagréable de voir les différences de salaires avec les managers ou les commerciaux, mais on ne peux pas décemment parler de pauvreté.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Victime
Posté par AncalagonTotof . Évalué à 4.
Tout est relatif : par rapport à mon N+1, je suis pauvre, je gagne deux fois moins.
Mais bien entendu, je suis loin d'être à plaindre.
Quoi qu'il en soit, l'utilisation du mot paupérisation ne me parait pas inappropriée.
[^] # Re: Victime
Posté par barmic 🦦 . Évalué à 1.
C'est pourtant objectivement faux.
Le fais que tu vois de plus gros salaire autour de toi ne dis pas que tu es entrain de t'appovrire. Ton pouvoir d'achat augmente plus que la moyenne des français. Sinon tout le monde pourra dire qu'il s'appauvri. Ton N+1 peut probablement dire la même chose et les plus grande fortunes de France pourront toujours dire qu'ils ne sont pas Jeff Bezos.
Oui tu te sens pauvre, mais la paupérisation est un concept objectif.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Victime
Posté par AncalagonTotof . Évalué à 1.
Où tu as vu que mon salaire augmente plus vite que la moyenne des français ?
Tu as dû oublier d'en parler à mes boss
[^] # Re: Victime
Posté par barmic 🦦 . Évalué à 8. Dernière modification le 22 juillet 2020 à 00:47.
L'article parle de la "paupérisation de notre métier" pas de AncalagonTotof. Je suis navré pour toi, mais tu n'es pas représentatif du métier. J'espère que ça n'affecte pas trop ton égo.
Il y a pleins de façons de s'appauvrire et ça n'est même pas forcément lié au salaire. Les éléments que tu donnais ne représentaient pas de l'appauvrissement, mais de l'inégalité. Tu es peut être payé sous le seuil de pauvreté. Encore une fois j'en suis désolé pour toi. Mais ton cas n'est pas assez représentatif pour argumenter que les développeurs s'appauvrissent
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Victime
Posté par romi . Évalué à 3. Dernière modification le 24 juillet 2020 à 22:05.
et oui il y a toujours plus pauvre!
j'ai connu des très bons salaires (genre 6500€ net) et le RSA donc j'ai une petite idée de ces extrêmes
mais alors l'argument "il y a pire" c'est bien du nivellement par le bas
bien sûr qu'on vit toujours mieux en France qu'au Bangladesh, le problème c'est le "toujours" car on pourrait se demander pour combien de temps encore ?
bref moi aussi ça m’innerve!
[^] # Re: Victime
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 24 juillet 2020 à 23:22.
J'ai donné un autre lien les salaires dans le milieu progressent plus que l'inflation. Donc encore un certain temps et même avec les écarts de salaires qu'il y a il faut un certains temps juste pour entrer dans le salaire moyen et je ne compare pas avec je ne sais quel pays, mais avec tes voisins.
On peut parler de pleins de choses pour se plaindre (la pression, le burnout, la reconnaissance, etc). Mais parler de pauvreté quand on fait parti des 20% les mieux payés d'un pays très riches, ça n'a pas de sens.
Ce n'est pas une question de nivellement par le bas mais d'inégalités. Sachant que la richesse n'est pas une valeur absolue, c'est une différence.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Victime
Posté par barmic 🦦 . Évalué à -1.
Sur quel base tu construit cet argument ? Ton ressenti du moment ? Sincèrement questionne d'où ça vient et tente de le remettre en cause. Avec l'augmentation de la production de logiciel bien sûr qu'il y a des gens qui ne savent pas s'y prendre qui font de la mauvaise MOA. Mais est-ce qu'il n'y a plus de gens qui considèrent leur logiciels comme un investissement ? Là où je travaille c'est le cas en tout cas (du moins de mon ressenti). Est-ce que tu ne te focaliserais pas sur certaines déconvenues ?
Après il faut chercher un peu pour trouver un travaille qui te convient, mais bon, c'est logique que dans un marché un peu concurrentiel, avec un certaines exigences comme tu semble l'avoir, il faille cherche pour trouver un boulot qui te convienne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Tldr;
Posté par raum_schiff . Évalué à 5.
Oui, Hélas !
[^] # Re: Tldr;
Posté par barmic 🦦 . Évalué à 2.
« Pour écrire ce commentaire », la suite de mes commentaires montre que non j'ai lu la suite. Mais rien dans la suite ne remet en question mon commentaire : l'ensemble du billet de blog parle de ressenti, d'une expérience personnelle et tente d'en déduire une vérité générale.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tldr;
Posté par ponceto (site web personnel) . Évalué à 3.
Votre ressenti sur ce que j'ai exprimé dans mon billet est disons intéressant. Je ne l'ai pas du tout rédigé en souhaitant énumérer et asséner des vérités absolues et peut-être êtes vous passé à côté de mon sujet. Si tel est le cas c'est que je n'ai pas été assez précis. Mais ce n'est pas bien grave, chacun son interprétation. Je trouve juste dommage que le ton employé et que je ressens (car c'est du pur ressenti) dans vos commentaires soit si négatif ou agressif … ou peut-être pas agressif, un peu entre les deux :-/
[^] # Re: Tldr;
Posté par barmic 🦦 . Évalué à 3.
Mis à part quand tu parle de paupérisation (mais là c'est assumer parler de paupérisation pour un boulot où la majorité des gens sont dans les 20% les mieux payés du pays me semble sincèrement abusif), je ne vois pas le coté agressif. Je remet en cause les conclusions, je questionne, je dis même clairement que je respect ton ressentis,… Si tu as des points plus précis, je suis intéressés de les entendre pour m'améliorer.
Pour le coté négatif, là je ne vois pas du tout, je trouve mes commentaires bien plus positifs que les autres. Au lieu de voir négativement l'évolution du domaine, je propose de chercher un point de vu positif.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tldr;
Posté par ponceto (site web personnel) . Évalué à 6.
Pour préciser, le terme "paupérisation" n'est pas à prendre au sens littéral (c.a.d l'argent, le salaire), mais plutôt dans un sens figuré (appauvrissement du métier). Sinon effectivement je ne peux qu'être d'accord sur le fait que nous sommes privilégiés en terme de revenus, là il n'y a pas de débat.
[^] # Re: Tldr;
Posté par pasBill pasGates . Évalué à 5.
J'ai à peu près le même âge et je suis passé de mes débuts à bosser sur les entrailles d'un OS en ASM-C-C++ à faire ce que tu appelles du "cloud" (du côté sécurité).
Il y a certes une "altitude" diffèrente par rapport au hardware, on opère avec des abstractions, mais il y a tout un tas de problèmatiques propres à ces environnements qui sont très intéressantes d'elles mêmes.
Alors oui, si l'objectif et de passer sans rien changer des VMs sur un cloud, c'est inutile et juste un buzzword, mais si on essaie véritablement de les utiliser alors c'est rempli de choses intéressantes à essayer et construire.
Perso, je me demandes à quel point ton problème est que tu es dans un confort, quelque chose dans lequel tu as baigné pendant des années, et devoir passer à un autre monde t'emmerde un peu. C'est normal comme sensation hein, mais il faut savoir la reconnaitre pour la gèrer.
[^] # Re: Tldr;
Posté par ponceto (site web personnel) . Évalué à 3.
Je pense que la question du confort n'est pas le point du billet, d'ailleurs je l'évoque dans la partie biais de statu quo. Je pratique tous ces outils, etc, et ce qui m'emm… comme tu dis est plutôt un constat général concernant nos métiers et c'est un point de vue absolument personnel et qui n'engage que moi, ce n'est pas une vérité absolue.
[^] # Re: Tldr;
Posté par barmic 🦦 . Évalué à 4.
Je comprends. En ayant beaucoup plus de personne dans le métier il y a forcément un niveau moyen plus faible, mais il y a largement toujours de la place pour des gens pointus. Il y a, je pense, un certain nombre de membres ici qui en sont la preuve. Il ne faut pas se laisser distraire par une partie des développements fait avec une mauvaise organisation ou très peu de compétences. Il y a encore de quoi exprimer son talent (et je vois ça sans être à Paris et sa banlieue).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tldr;
Posté par raum_schiff . Évalué à 3.
Ponceto n'infère rien, c'est un témoignage à prendre comme tel.
Si tu ne t'y retrouve pas, c'est que cela ne correspond pas à ton expérience.
Sa "déduction" est assez optimiste et finit par des remerciements.
[^] # Re: Tldr;
Posté par barmic 🦦 . Évalué à 3.
Il parle lui-même de "constat général" juste au dessus.
Tout à fait et c'est bien pour ça que j'essaie de dire qu'il s'agit d'un ressenti et que ça peut être intéressant de voir d'où il vient pour pouvoir le questionner. Pourquoi ? Parce que ce ressenti (voir ce ressentiment) lui a fait du mal.
On a tous nos parcours, nos émotions, nos sensibilité, c'est bien et c'est vrai. Mais quand elles en arrivent à nous faire mal, ça peut être bien de prendre du recul pour les comprendre.
D'autres part pour pouvoir échanger et pas simplement tous énumérer nos ressenti, il est intéressant de partir des causes.
Je dirais douce-amère plutôt qu'optimiste.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Dans la même veine...
Posté par HL . Évalué à 3.
Tout cela me fatigue…
# Bienvenue au club !
Posté par Christophe B. (site web personnel) . Évalué à 7.
Tes mots me parlent et ton ressenti aussi
J'ai commencé il y a plus longtemps que toi, environ 10 ans, a une époque AVANT internet et les réseaux, les ports USB etc …
Avec un parcours similaire : ZX81, VIC20, CBM64 et amiga, par contre j'ai jamais pu faire de C a une époque les compilateurs coutaient trop chers.
Et comme toi, j'aime bien le terme d'artisan, "qui met son art au service d'autrui".
Heureusement, je n'ai pas fais de burn out. Bien que je connaisse très bien ce que cela signifie, le problème c'est qu'il y a un cas par personne et il est difficile de généraliser la dessus.
Une espèce en voie d'extinction, j'espère bien que non ou alors le film IDIOCRACY a raison et on est tous foutu.
Il y en aura toujours qui aimeront le travail bien fait et il y a aura toujours besoin de personnes compétentes, et de plus en plus car le monde est de plus en plus complexe.
Tu viens juste de découvrir que l'informatique est devenu comme la musique beaucoup de consommateur mais très peu de créateur talentueux
Possèder un "smartphone" (rien que le mot m'amuse) ne rend pas plus intelligent … tout le monde peut sortir un son depuis une guitare voire même quelques notes que l'on peut facilement reconnaître … mais combien existe t il de Mark Knopfler (je mets quand même le lien pour les plus jeunes …)
Et dans notre cas, on passe progressivement de "jeunes fous" à … "vieux cons"
- je vous l'avais bien dit …
- c'était mieux avant …
- de mon temps …
- une bonne guerre …
- bande de beatnik …
- tous des tarlouzes …
- il n'y a plus d'hommes …
- c'est le progrès …
bref j'en passe et des meilleurs
Mais c'est normal, c'est dans la nature des choses, a une époque certaines personnes ne connaissaient que les "anciens francs" et certains ont quand même survécu à l'euro …
Tout cela pour dire que bientot cela ne t'amusera plus de dire : 'je vous avais prevenu'
et tu laisseras venir les fou furieux te consulter comme le Sage que vas devenir :)
Tu as appris a tes enfants le danger du feu ou du chaud, le mieux c'est qu'ils expérimentent par eux mêmes, ton boulot n'est pas de les soustraire à la douleur mais c'est d'éviter la brulure.
L'idéal serait de monétiser cette transmission de savoir jusqu'à la retraite, transmettre ce que l'on a appris a ceux qui en ont besoin, et la il y a du boulot !
Si tu trouves un école en ligne qui a besoin de vieux Sage … préviens moi je ferais de même :)
Sinon tu peu aussi écrire un livre ;)
# Tu n'es en rien en voie d'extinction
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 21 juillet 2020 à 21:55.
Je précise que je suis ingénieur soft et je fais surtout du C++, je connais le bas niveau et je comprends ce que tu ressens.
J'ai travaillé avec suffisamment de dev/pseudo-architecte qui ne comprennent absolument pas ce qu'ils font et qui vont pourtant militer avec toute la confiance du monde pour te déployer un kubernetes, un kafka, 5 bases de données et 150 micro-services pour faire tourner un blog.
1 - Ton profile n'est absolument pas en voie d'extinction
Toute structure suffisamment large a besoin de personnes qui comprennent l'infrastructure du top au bottom. Ils sont d'une valeur incommensurable à la boite car ce sont eux qu'on vient chercher en cas de pépin, de gros pépin. Si ta boite ne comprends pas ça, change de boite.
Je peux te donner une 10ene de secteurs et une 20ene de boites que je connais qui recherche des personnes avec ton profile. Hors France. La mienne inclue (on vient de terminer une campagne de recrutement avec 5 dev C++ )
2 - Nous vivons dans un monde où les bons éléments manquent d'assurances et où les imbéciles sont sur de soit
On appelle ça le syndrome de l'imposteur versus le narcissisme.
Tu auras toujours des imbéciles qui militeront dans ta boite avec toute la confiance du monde sur des technos qu'ils ne maîtrisent ni d'Eve ni d'Adam et qui voudront te pusher ça en production sans aucun garde fou.
Il faut apprendre à les gérer ou les raisonner. C'est le seul moyen de faire avec.
La clé pour ça c'est la communication.
Généralement pour le reste, le temps fait son office: les zélotes fanatiques finissent par se bruler trés bien tout seuls. Et finissent soit par se faire virer, soit par se faire promouvoir au placard à balai.
Ce que tu décris là c'est de l'immaturité. Le développeur qui a suffisamment d'expérience comprend le légacy et le respecte. On ne remplace le légacy que si le cout de maintenance dépasse de loin le risque et les ressources pour la ré-écriture.
3- Relativiser
L'IT a besoin de personnes qui "move fast et break things", c'est nécessaire au progrés.
Toute entreprise pérenne a besoin de personne qui connaissent ce que c'est que de maintenir un service en production et le faire évoluer pendant 10 ans.
Les deux sont opposés mais les deux sont indispensables.
Les premiers font évoluer les seconds. Les seconds sont là pour raisonner les premiers.
Manager ça, c'est un boulot autant humain que technique.
4- Trouve toi une occupation en dehors du travail
Si tu es comme moi, et que l'informatique est à la fois une passion et un travail. Tu as très certainement une forte tendance à maximiser ton temps devant l'écran, même en dehors du travail. C'est encore pire en période de confinement.
Le boulot c'est le boulot, le plaisir c'est le plaisir. Je pars du principe que tout ce que je fais après les heures de travail ne touchent pas au travail (même de loin). C'est le seul moyen de ne pas finir en burnout.
Tout le monde est humain.
5- Ne pas se battre contre des moulins à vent
Ne change pas de métier, l'IT a besoin de personnes avec ton profile… qui aime comprendre les choses et pas seulement les utiliser.
Si par contre, c'est ton environnement qui est toxique, avec des personnes haineuses, agressives et méprisantes: Change d'environnement.
6- Conclusion: Ne pas prendre pas sur soit
Je pense pas le moindre du monde que ton profile soit 'en voie d’extinction'.
Que les gens avec ton profile soit une minorité: oui c'est certain.
Qu'ils soient inutile ou en voie d’extinction: non vraiment pas.
My 2 cents.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Anonyme . Évalué à 5.
pour la communication, je suis plutot pour, j'ai suivi une formation sur bayonne, s'afirmer sans s'imposer, a base de CNV (communication non violente)
après 1 an de pratique, je dirais que les horreurs dans le code/document je les remonte gentiment et curieusement sa passe mieux, et parfois cela fonctionne il accepte de le changer.
maintenant je dis plutôt :
le JUMP est de trop dans le code cela apporte un risque, je suis vraiment embété, je n'aime pas du tout cela, j'aurais besoin d'un peu de factorisation sur cette partie, je demande a l'equipe A d'apporter ces corrections d'ici 1 mois.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 22 juillet 2020 à 00:59.
Plus que gentiment c'est factuellement et en exprimant tes besoins, non ? (après "je n'aime pas" et du pathos n'ont pas leur ce dans une revue amha)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Julien Jorge (site web personnel) . Évalué à 4.
Il y a des trucs sur lesquels j'ai du mal à faire des retours en revue. Quand il y a un problème du genre « ça ne fonctionne pas », c'est facile, mais quand c'est un problème de façon de faire, c'est dur à justifier.
Par exemple quand je vois passer des acronymes, des abréviations, des fonctions de cinq kilomètres, des dépendances inutiles dans les headers, de l'objet pour que dalle… C'est sûr ça fonctionne, mais niveau hygiène c'est pas génial. Quelle galère de lire du code comme ça. Quelle galère de revenir là dedans après quelques mois, et quelle tristesse de se traîner ça sur toute la vie du projet.
Et du coup à part faire une remarque personnelle disant que mon expérience et mes lectures m'amènent à penser que c'est médiocre, éventuellement en pointant un paragraphe d'un bouquin ou un article en guise de source externe (et bonjour l'effort pour retrouver mes sources), je ne vois pas trop comment faire pour encourager à faire du code propre.
Comment faites vous pour faire des retours sur ce genre de soucis ?
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Ce bouquin à l'air d'être une référence sur la définition "d'un code professionnel":
https://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Le terme "dette technique" m'énerve, mais il est bien définit dans ce livre. Un soft est écrit pour être modifié, sinon il finit par mourir. La dette technique est le prix que tu payes parce que le code est sale, peu lisible, peu clair, verbeux, trompeur, moche…
"La première sécurité est la liberté"
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Liste de propriété donné par le livre :
https://damien.pobel.fr/post/clean-code/
"
- Keep it simple stupid. Plus simple est toujours mieux. Réduisez la complexité autant que possible.
- Règle du boy scout : laissez le camp plus propre que l'état dans lequel vous l'avez trouvé.
"
"La première sécurité est la liberté"
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Julien Jorge (site web personnel) . Évalué à 4.
Alors j'ai lu ce livre et effectivement c'est un de ceux que je pointe. Je fais aussi référence à Code Complete.
C'est plein de bons conseils et lire ça me semble être un bon moyen d'acquérir une sorte d'expérience de plusieurs décades de développement avant nous. Mais que faire quand les autres ne l'ont pas lu ? Pire, que faire quand ils ne sont même pas intéressés par la notion de code clean ?
Il y a aussi des principes qui ont un peu vieillit dans ces livres. Dans le lien de blog que tu donnes plus bas il y a un lien vers un autre article qui explique que le DRY se fait avec modération. Oui, factoriser à tout va pose aussi des problèmes. Oui je m'y suis aussi brûlé.
Pareil pour le fait de favoriser le polymorphisme à la place d'
if/elseouswitch/case. Ça se discute. Des fois c'est plus clair d'avoir tous les cas à plat dans unswitchplutôt que d'avoir plein de classes qui éparpillent la logique.[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 22 juillet 2020 à 10:33.
C'est pour ça que j'ai parlé de la dette téchnique, car il y a le ROI derrière.
Cette partie-là m'a fait beaucoup réfléchir. Surtout que je viens de l'Ocaml ou l'on passe sont temps à faire des gros pattern matching sur des arbres, soit en fait, des gros switchs.
Cela colle parfaitement avec sa définition du ouvert/fermé de SOLID.
( https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle )
Un code fonctionnel permet de rajouter facilement un traitement sur des données qui ne bougent pas (exemple un compilo en OCaml, la langage change peu). Un code objet permet facilement d'ajouter un objet dans des données pour des traitements qui ne bougent pas (exemple : un code business en Java qui s'étend mais dont les nouveaux traitement touchent peu les anciens objets).
Je suis en train de faire un code suivant ce principe (remplacer les switch par du polymorphisme), cela permet d'avoir plein de petits objets. Par contre, j'ai toujours un gros switch moche dans une factory.
"La première sécurité est la liberté"
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Dr BG . Évalué à 6.
Ce qui est aussi dit dans Clean Code, c'est qu'il présente ce qu'il considère être du code propre : tout le monde ne sera pas d'accord avec lui, mais faut au moins y avoir réfléchi et avoir des bonnes raisons d'être contre.
Dans les revues, quand je trouve un truc pas terrible, j'explique ce que j'aurais fait à la place et je demande s'il y a une bonne raison d'avoir fait comme ça. Soit la personne répond qu'elle trouve aussi la proposition mieux, soit elle explique ses choix (qui ont effectivement une justification valable), soit ça se passe mal parce qu'elle n'a pas d'argument et n'a juste pas envie de réfléchir, mais c'est plus rare.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par barmic 🦦 . Évalué à 2.
En même temps on s'en fout de faire du clean code :p Ce qui est intéressant c'est ce que ça apporte ou non.
Les règles sont comme les designs patterns, ils ne sont pas intéressants en eux-même, ils constituent juste une façon simple de communiquer. Il est plus simple de dire que l'on respecte la loi Demeter plutôt que d'expliquer quel couplage on cherche à éviter.
C'est un travail qui est intéressant lors de revues, en quoi ce que je vois pose problème ? Ce n'est pas une question de beauté du code, mais de propriété qu'on veut obtenir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Firwen (site web personnel) . Évalué à 3.
C'est vrai, mais partiel.
La dette technique ne s'arrête pas uniquement au logiciel et au code.
Une mise en prod rapide et sale mal configuré peut-être une forme de dette technique. Cela rendre la maintenance du service (E.g l'administration de sa database ) plus dur par la suite.
Je résumerai la dette technique pourrait être résumé en "Tout ce qui a été fait à crédit, c'est à dire mis en place de manière non durable, généralement due à des contraintes temporelles, et qui par conséquence devra être payé plus tard (avec les interets, le cout de maintenance) ".
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par barmic 🦦 . Évalué à 4.
Je suis d'accord avec toi sauf sur le coté négatif de la dette technique. Comme pour la dette des états, il est normal d'avoir de la dette ce n'est pas une mauvaise chose, c'est quelque chose qui arrive mécaniquement. Il est normale de ne pas toujours investir dans la dette technique, ce qu'il faut c'est que ce soit quelque chose de maitrisé et d'accompagné. Mais l’absence de dette technique ça n'existe presque pas.
https://www.linformaticien.com/dossiers/le-lourd-poids-de-la-dette-technique.aspx
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par fearan . Évalué à 4.
Pas que, cela peut être lié à :
* l'âge des bibliothèque (ou technologie de ces dernières): une mise à jour de ces dernière peut réclamer du temps
* l'âge du code; typiquement le passage à c++11 à changé la façon de gérer pas mal de chose; les emplace dans les conteneur, la move sémantic, les lambdas… ou la disparition des auto_ptr dans c++17
* obsolescence des procédure. Là encore cela se ressent sur de vieux logiciel, certaines fonctionnalités ne sont plus utilisées depuis plusieurs années, et le code derrière maintenu pour la compilation, mais en pure perte; le soucis c'est que 'au cas où', on le garde. Note bien j'ai aussi eu le pour 'le garder en exemple'.
Ensuite il y a toute la dette due à la précédente, les contournement parce que la bibliothèque ne gère pas correctement les accents ou caractères spéciaux, usage de struct là où aujourd'hui on utilise une lamda, ou en java l'utilisation des stream ou closable.
Bref la dette technique n'est pas que le fait des développeurs; même s'ils y contribuent grandement.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Guillaume Rossignol . Évalué à 6.
Sur tout ce qui est "simple", je fais le correctif dans une PR à part en mode "Je trouve ça plus clair à relire/comprendre vous en pensez quoi ?". Ça prend pas plus de temps que de pointer les abréviations et de partir dans des débats compliqués, et ça marche souvent.
Pour le reste («l'objet pour que dalle», «les fonctions de 5 kilomètres»), c'est normalement assez facile d’être plusieurs dans l'équipe a appuyer le fait que c'est pas terrible et que ca vaut le coup de passer un peu de temps à remettre d'équerre.
Dans une de mes boites, on a fait de la code review en équipe de code pas à nous (pour comprendre comment fonctionne une lib ou un outil qu'on utilise). Ça permet d'arriver à des conclusions consensuelles du genre :
- C'est chiant à lire les fonctions de plus de deux écrans,
- Mais pourquoi il y a 15 couches d'abstractions pour un truc qu'on ne peut pas modifier,
- Mais pourquoi ce concept change de nom juste dans cette classe ?
En gros, passer par du code neutre (qui n’était fait par personne dans la boite) a permis de virer l'aspect affectif dans la critique du code et sortir des règles validées par tout le monde.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par barmic 🦦 . Évalué à 5.
Ce donner des règles de programmation et les enforcer par la CI c'est utile aussi.
Pour moi :
C'est une remarque qui ne devrait pas exister en revue. Si tu as passé quelques secondes pour lire/remarquer/faire un commentaire sur quelque chose qui peut tout à fait être automatisé, tu as cassé le fil de ta réflexion pour faire des remarques à plus haute valeur ajoutée. L'idée c'est que si la revue sert à faire linter comme peuvent le faire les linters, les outils d'analyse statique ou les éditeurs évolués tu as perdu du temps et de l'énergie sur quelque chose qui peut apporter plus à tout le monde.
C'est pas mal établir les règles de programmation. Merci pour l'astuce.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Anonyme . Évalué à 2.
avec la cnv ca donnerait
il y a des dépendances inutile dans le headers, je suis un peu triste niveau hygiène c'est pas génial, j'aurais besoin que cela soit corriger, pouvez vous regarder cela lors de le revue du vendredi 18 sinon est ce que je peux le corriger ?
la structure est toujours la même :
des fait précis, tes sentiment, ton besoin, ta demande précise.
ca fonctionne pour le négatif et l'humain, mais la formatrice nous a expliqué que si le gars est très con, il risque de le resté mais c'est plutôt rare. et c'est mieux de commencer par des truc très simple :) pour voir l'efficacité.
éviter : je suis mal payé, je suis triste, j'ai besoin de beaucoup d'argent, je te demande de m'augmenter de 2000€
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par ckyl . Évalué à 5.
Honnêtement je ne trouve pas ça bon. Il n'y a aucune information utile dans ce message. Le ton est plutôt hautain et la plupart des mots sont juste du remplissage. Cela ne me donne pas envie de travailler avec toi. Je pense qu'un simple "Peut-on éviter le JUMP?" passerait bien mieux. Explication du problème ou ébauche de solution en bonus.
Personnellement mon approche est:
J'ai travaillé avec pas mal d'équipe et de gens. La plupart sont plutôt ouverts, contents d'apprendre et d'échanger quand tu apportes humblement de la valeur technique. Les mêmes remarques exprimées de façon sèches passent mal. La progression globale à long terme est vraiment différente.
Je trouve l'effort d'argumenter ses points très enrichissant. Cela permet de faire le tri entre préférences, certitudes, approches possibles et vérités.
Même chose sur l'expertise et l'analyse dont il est mention plus haut. Tu peux être l'expert bougon dans son coin qu'on sort de son placard quand tout vas mal (cf. plus haut). Mais tu peux aussi faire la même chose en prenant des gens avec toi et en leur apprenant comment on fait. Au passage tu leur montres comment on peut penser à ce genre de problème à la conception ou instrumenter son produit plutôt que d'aller faire le sauveur quand c'est trop tard.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par Anonyme . Évalué à 2.
c'est une méthode de communication. L'avantage je trouve hors le fait que c'est peu efficace pour résoudre un pb :) car ce n'est pas son but, c'est qu'en fonction de ton caractère tu arrive a exprimer ce que tu veux. Pour les introvertis maladif ca les aide a oser faire des mails. La demande n'est pas forcement impérative comme dans mon exemple, pourrait on regarder cela ensemble ? qu'en pense tu ? pourrais tu m'aider etc …
si tu es dans le besoin et en demande, le collegue/l'equipe va avoir envie de lui même de t'aider, et la deuxième étape d'une communication établie passe pas la résolution du pb comme tu le fait.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par ckyl . Évalué à 6.
Les trois phrases que tu as données dans tes différents commentaires sont pour moi des repoussoirs. Sûrement à la fois pour leurs mauvais ratio signal / bruit, le fait qu'exprimer tes sentiments me semble inadapté à une revue de code, et surtout pour la structure mécanique et automatique évidente. J'ai l'impression de parler à quelqu'un qui vient de se faire lobotomiser par un formateur d'entreprise quelconque.
Tant mieux si ça (t')?aide. Mais étudier les interactions sur des projets OSS pour identifier ce qui fait des bons retours que l'on apprécierait recevoir (pertinence, conseils, empathie) me semble beaucoup plus judicieux à long terme. L'ancienne communauté OSS était techniquement très pointue mais aussi extrêmement violente. Nombre de projets plus récents ont réussi à passer ce cap et son des environnements de travail plutôt sains, on a donc un large éventail d'exemples.
[^] # Re: Tu n'es en rien en voie d'extinction
Posté par moulator42 . Évalué à 2.
Lesquel(le)s ? Je suis dans la même recherche mais trouve pô…
# Si vous êtes arrivés jusque là, bravo !
Posté par _kaos_ . Évalué à 6.
Salut,
Juste quelques mots.
Déjà, merci pour le retour.
Moi, ça a été plus simple (déjà j'ai pas d'enfants, donc beaucoup plus simple). Et parce que j'avais déjà fait l'expérience, de manière volontaire, pas sur imposition, de couper quasi tout de social il y a pas mal d'années pour un gros projet pendant environ 6 mois.
Je savais comment ça allait tourner si je ne m'imposais pas de règles. Un peu plus strictes que d'habitude.
L'ayant déjà fait de manière volontaire comme dit, je sais ce qui se passe. Au début on perd un peu la notion d'heure. Ensuite, les jours, puisqu'ils se ressemblent tous. Et à la fin, on ne sais plus trop où on habite, s'il faut travailler, se reposer, manger…
Là, deux mois, malgré les soucis, en utilisant l'expérience précédente, c'est passé tranquille. Je savais déjà tout :)
Je dois être un dinosaure aussi !
Matricule 23415
# L'embarqué c'est la vie
Posté par gUI (Mastodon) . Évalué à 5.
Pas de Java, pas de virtualisation (sauf chez certains tordus d'esprit), que du bon vieux microcontrôleur avec ses registres et ses champs de bits. Au mieux t'as un Linux embarqué et il faut du monde pour regarder le bootloader ou le partitionnement de la flash.
Bref, qqu'un qui SAIT comment marche un ordi a encore bcp, bcp, bcp de boulot devant lui avec la mode de l'IoT et de l'embarqué en général.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: L'embarqué c'est la vie
Posté par _kaos_ . Évalué à 2.
Salut,
Ah nan mais attends. L'embarqué, c'est galère !
Matricule 23415
[^] # Re: L'embarqué c'est la vie
Posté par ckyl . Évalué à 7. Dernière modification le 22 juillet 2020 à 21:26.
Heu je fais du Java, de la virtualisation, du cloud… mais je peux t'expliquer comment marche le compilo, le JIT, étudier le code assembleur produit, le profiler, tracer ou débugger le noyau ou le GC. Ca marche aussi avec comparer le fonctionnement avec d'autres langages, le réseau, les systèmes distribués etc. Je me considère juste comme un couillon compétent mais pas plus que les centaines de mecs que j'ai pu croisé sur différent projets.
J'ai l'impression que vous avez beaucoup trop d'a priori sur "Je fais du C/C++/admin depuis 20 ans, je suis un bon les autres sont des cons". L'informatique est tellement large qu'il est impossible d'être bon partout ni de prétendre détenir la vérité. Différents domaines demandes différentes approches et outils. La compétence ça me semble surtout de développer un beau profile en "T", être capable de communiquer clairement son savoir et attirer les personnes avec qui on a envie de bosser.
[^] # Re: L'embarqué c'est la vie
Posté par Dr BG . Évalué à 5.
Ah mince, moi je fais du Java pour de l'embarqué, mais pas de Linux, c'est trop gros 😉
[^] # Re: L'embarqué c'est la vie
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 25 juillet 2020 à 14:03.
Merci pour ces contres arguments qui sauront redonner moral à l'auteur du journal : qqu'un qui SAIT comment marche un ordi aura toujours une plus-value.
Et désolé pour l'attaque gratuite sur Java, les familles toussa…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: L'embarqué c'est la vie
Posté par Donk . Évalué à -1.
L'ordi marche en mettant un pied devant l'autre.
:D
# un problème de riche
Posté par MrBidon . Évalué à 5.
En France, la valeur du matériel est inférieure à la valeur du travail d'un ingénieur. Une bonne machine vaut 10 K€ soit l'équivalent environ 1 mois et demi du travail d'un développeur. Cela car nos chers serveurs sont fabriqués dans des pays moins regardant sur le régime social des travailleurs ainsi que leur âge (et je ne parle de pas de l'extraction des minerais qui composent ces machines). De plus, nous vivons dans un pays riche, l'argent n'a jamais été aussi facile à obtenir avec la BCE qui distribue des Euro à tout va, via le système de création monétaire via le crédit, je pense que nos chères sociétés informatiques (ESN, start-up, grand groupe) sont très fortes pour souscrire à du crédit à taux si bas. Pour moi, depuis 2009 nous (les pays riches) nous complaisons dans une bulle financière délirante. On vend les leaders de l'industrie (Alstom, Archelor…) pour les remplacer par des sites web (les nouvelles "licornes" française sont Blablablacar , Doctolib…). La magie c'est que ça marche (en apparence) car dès qu'il y a une menace d'explosion de la bulle, de l'argent est fabriqué par ce biais. Cela s'arrêtera quand il n'y aura plus de minerais, de pétrole ou d'uranium… aucune idée de quand ça arrivera, c'est pas encore pour tout de suite visiblement.
# Pour aller plus loin :
Posté par PiSur12 . Évalué à 1.
Et même beaucoup plus loin sur ce sujet :
https://www.editionsladecouverte.fr/catalogue/index-_loge_du_carburateur-9782707160065.html
Tu vas voir, le problème n'est pas lié à l'informatique, n'a pas commencé il y a 25, 30 ans et va encore prendre de l'ampleur …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.