Reprise du message précédent :

Passer son temps à lire le code des autres, quel enfer ça doit être.

La gestion de la dette technique et la nécessaire rigueur afférente fait en sorte que dev c'est un boulot extrêmement ingrat, oui.
 
Si je voulais troller, je dirais que c'est un boulot pour psychorigides...

 
Horrible parfois je me demande si on est sur HFR où sur SFR

 
Ben c'est là où la parti sur l'aarchitecture de l'appli est hyper importante. Sur un monolyth c'est suicidaire. Sur une archi modulable / well sized services / Microservices ça s'y prete bien et c'est un gain de temps en 2026
 

Software engineers. Habitués au peer programming et à transformer l'industrie de la data/IA/calcul distribué plusieurs fois par décennie (j'aimerai exagérer mais le budget R&D est en rapport avec ces résultats )
 

Alors finalement pas tant mais en effet c'est pas toujours drôle de courir après ses reviewers, voir des sommités revoir parfois ta petite change list qui fait un truc de rien du tout ou fin fond de l'infra ou des débats sans fin sur un détail d'un commit où deux personnes ont raison en même temps. Pendant longtemps il fallait obligatoirement deux peer review du coup : en cas de boucle infini entre un dev et son reviewer le second servait de quorum pour prise de décision sans escalade au mangement. Aujourd'hui l'IA revoit le code, pose des questions et approuve / rejette un change list de manière autonome avec toujours un humain pour quorum/double vérification.

 
Ils viennent toujours de partout.
Sans étrangers, les labos ne tournent pas

J'en vois encore plus qui sont dans le phantasme  

 
eh oh !

 
Quand ton metier est fait majoritairement par des etrangers, cela veut malheureusement dire qu’il n est pas assez attractif pour les locaux.

 
Non, absolument pas.
Ca peut aussi vouloir dire que les compétences sont rares et que tu dois "ratisser" large. La science est mondialisée depuis qu'elle existe.

LinkedIn c'est le site à coté
( l'impression de voir une accumulation de buzzword, le couplet old school sur les monolithes et la "recette magique" des microservices, le "archi modulable" - on croirait un discours Miss France sur la paix dans le monde - etc...).

 
Je me demande qu'elle serait ta situation financiére à 70 ans si on te supprime les quotisations retraite entiérement là (dans les 2 pays), si on te donne juste l'équivalent de ce que ta cotisé à 67 ans genre 1200-1500 brut et c'est tout et que doive compléter via ton épargne uniquement c'est à dire qu'il te faudra épargner un petit 500K-1 million pour gérer le manque à gagner...

 
C'est logique de taxer le revenu quel qu'en soit la source. Comme on taxe le chomage ou les revenus du capital. A la fin l'impot sur le revenu est déjà progressif de toute facon. Donc si ta une retraite toute petite tu paye quasit rien.

Il a du voir la vidéo d'une conf sur youtube

LinkedIn, l'enfer des improductifs

 
Le temple de la génance avec tous ces gens en self marketing permanent  

 
L'essentiel de l'effort dans l'industrie du logiciel n'est pas d'écrire le code initial mais de le maintenir. On considére souvent que 90% du cout est la maintenance et 10% produire le code initial. Il faut non seulement garder leur serveurs opérationnels, mais fixer le bug et toute nouvelle fonctionalité ajoute de la complexité.Complexité qui est exponentielle avec la taille du dit logiciel. Les dev passent 90% de leur temps de coding à gérer le code existant, pas à en écrire du nouveau.
 
Les fonctionalités de base même avant IA, si tu maitrise ton sujet, tu va les développer trés vite. Refaire whatsapp ou facebook tu fait ca en un weekend. Genre juste un chat ou juste une page ou des gens vont mettre leur profil.
 
Mais personne est intéréssé par ca car ca marche pas vraiment.  C'est toutes les fonctionalité en plus auquel les gens ne pensent pas, et qui se comptent par milliers qu'il faut ajouter. Au final de loin ca semble pas trés différent, mais le cout lui n'a rien avoir.
 
Par ailleur, refaire tout de base est une stratégie populaire mais le plus souvent vouée à l'échec. Netscape à fait faillite comme ca. Une entreprise pour qui j'ai bossé y'a 15 ans est pas passé loin de la faillite en voulant faire la même chose. Et ils ont jeté le nouveau logiciel à la fin car il avait trop de problémes et il pouvaient pas dépenser des millions 5 ans de plus pour le rendre utilisable.
 
Le probléme c'est qu'en vrai refaire tout ca prend 5-10 ans ou plus selon la complexité du truc. 10 ans pendant lesquels tu fait 2X en cout. Faut maintenir l'ancien, dev le nouveau et migrer. Pendant ce temps la qualité baisse et tes client fuient ton nouveau logiciel incomplét et plus instable vs l'ancien.
 
La solution sage est souvent différente, tu refait petit bout par petit bout pour gérer le risque.

 
Il n'y a pas de différence entre les salaires des fonctionnaires et leur retraite : dans les deux cas ce sont les actifs français du privé qui les financent.
 
Si tu ne veux pas que le contribuable francais paye les fonctionnaires et leurs retraites, qui doit les financer selon toi? (parce que si ta conclusion, c'est "je ne veux plus financer les fonctionnaires et je suis prêt à accepter es conséquences", je doute que ce soit l'avis du plus grand nombre)

Oui bien sûr c'est normal de lire du code existant quand tu travailles dedans. Je me suis mal exprimé.
Je parlais de lire du code des autres dans le sens de faire des code reviews pour des pull requests des collègues. Je trouve ça horrible.

C'est pas une recette magique. Il y a plein de cas de métier où c'est plus efficace de faire un monolithe (ne serait-ce que pour des raisons de performance / coût d'hebergement). Mais passé un seuil c'est difficile à maintenir / contrôler / faire évoluer efficacement. Qu'on le veuille ou non
 

Y'a de très bons contenus sur le sujet. Y'a de très bonnes confs de Kelsey Hightower disponibles notamment

Oh non pitié ! Pas encore des slidewares ! Après on est en train de poster sur HFR vraisemblablement sur le temps de travail (A ma décharge j'ai pas d'horaire : je suis au forfait jour )  
 

Les retraites des fonctionnaires sont censées être financées par les cotisations retraite sur le salaire des fonctionnaires. Sous entendu avec des taux de cotisations "normaux" pas des taux qui font qu'ils ont un superbrut de trader avec un net de misère.
Ce n'est pas normal que mes impôts soient affectés directement au financement des retraites de fonx.

Suffit d'approuver sans regarder, ceci dit.

Il a peut être jamais besoin de l’hôpital / Écoles / routes / Police / Justice / Eau / bouffer (vu le déséquilibre du marché et le besoin massif d'aides aux agriculteurs pour à peine rattraper)

Oui, les rares fois où on m'a demandé de faire ça j'ai envoyé mon "lgtm" dans la minute

Normalement ça gratte un peu de savoir comment le copain d'en face a fait son bout d'app et de montrer qu'on est compétent aussi

 
A = salaire des fonctionnaires
B = cotisation des fonctionnaires
 
Quoi qu'il arrive, A et B sont financés par les impôts/charges/cotisations des gens du privés.
 
Si tu veux baisser ce que tu donnes aux fonctionnaires, il faut baisser A, B ou les deux (et comme c'est déjà la merde dans pas mal de métiers pour recruter des fonctionnaires vu qu'ils sont déjà moins bien payés que le privé...)

 
Ca reste une activité importante. Si tu laisse passer du code de m... il reste là souvent des années. C'est une tache complexe, car pour correctement revoir une PR, faut comprendre la tache globale que voulait faire la personne, faut maitriser le projet et faut faire des remarques/propositions qui sont pas trop agressive. Par contre du coup, ca permet de vite monter en compétance sur un projet vu que tu vois ce qui se passe et comment de nouvelles fonctionnalités sont ajoutés.
 
Ensuite faut convaincre les gens de fix... Si ton équipe est pas mature, les gens s'approuvent entre eux sans vraiment check et tu pourri vite le tout. A la fin développer et gérer un logiciel est une activité industrielle qui se fait en équipe et la qualité globale obtenue est pas mal lié à la qualité et organisation globale de l'équipe.
 
Pour aider sur les PR, c'est bien d'avoir un process qui décrit ce qui est attendu et quoi faire dans tel ou tel cas. L'automation aussi aide beaucoup. Avoir un max de checks automatique va faire gagner du temps et si c'est bloqué par le robot, c'est plus difficile de passer outre.
 
Ca ennuie beaucoup de gens comme reviewer et reviewed. Un truc souvent je trouve ce qui marche bien c'est de suivre à 2 des activités tout du long. Si ta bien suivit ce que fait ton collégue, genre qu'est qu'il fallait faire, les choix de designs etc, quand tu revoit le code, c'st beaucoup plus facile. Vous étes déjà allignés, ce qui est fait est clair et y'a peu de remarques.

 
Le montant de pas mal des aides sociales dépend déjà des revenus, donc c'est déjà pareil que si c'était taxé.

la base c'est déjà d'interdire de choisir son reviewer. Faut un tirage au sort basé sur la maîtrise d'un même language de quelqu'un pas directement dans la même équipe et si possible pas en vacances / arrêt de travail .  
 
Normalement le code doit être lisible : on a pas besoin de connaitre intimement tout le système pour approuver la qualité/logique du code. La partie intégration avec le reste de l'ecosystème de l'app c'est fait à la phase de design doc de la solution (qui est validé en équipe avec le team lead technique, le PM et qui est accessible dans la demande de revue)
 
Sinon c'est festival de relecture biaisée si il reste peu de temps avant la date de livraison

 
Le problème de tout mélanger c'est que certaines personnes pensent que le budget de l'éducation est énorme alors que les retraites prennent une partie de ce budget.
 
Du coup ces personnes ne pensent pas qu'il faille réformer les retraites, mais plutôt réformer l'éducation, et autres services de l'état. Car ils ne verront jamais que l'argent va aux retraités...

 
C'est pas un bug c'est volontaire. Comment tu veux taper sur les profs si on voit qu'ils sont largement en carence de moyens ? Et pareil comment tu veux contrôler les foules si les profs ont les moyens de transmettre un esprit critique et la capacité à d'analyser la rhétorique à la populace ?

 
Le code est lisible mais sans connaitre l'archi du produit tu peux pas dire par exemple si la PR fit cette archi. Tu peux pas savoir non plus si le code fait ce qui doit être fait si tu comprend pas finement le but de la PR et tu sais pas si la moitié est oubliée. Que le code soit lisible c'est le niveau 0 de la code review. la vrai valeur c'est de trouver des bugs ou des probléme de design, le code qui aurait du être écrit mais ne l'est pas ou si le code même si par lui même semble bien n'est pas bon ou mal placé. Connaitre les problémes typique en prod de cette appli permet aussi par exemple de t'assurer que ce genre d'écceuil est évité.
 
Edit: Aussi les grosses fonctionalité sont souvent délivrées en plusieurs PR, parfois 5-10 ou plus. Si ta pas le context global, tu sais pas ce qui a été déjà délivré et ne sait pas ce qui est prévu de délivrer ensuite, tu peux pas trop revoir la PR correctement.

On est un poil HS, mais en théorie les problèmes de design devraient être trouve en amont, bien avant la PR. Bon en pratique meme avec une phase de conception un peu detaillée, c'est pas toujours evident d'anticiper des problèmes de fond avant d'avoir commence (ou fini) l'implem. Mais ca fait toujours un peu chier de devoir jeter un gros diff "qui marche" pour un truc qui aurait pu/du être vu en amont, c'est jamais agréable.
 
Après je je rejoins sur le fait que si en théorie une PR devrait être auto suffisante, en pratique pour faire une review correcte, c'est quand meme beaucoup plus simple quand tu connais un minimum le contexte, les éventuelles taches liées qui vont suivre etc

C'est le but du design qui accompagne le code soumis et qui a été validé en équipe et en amont du développement justement pour ne pas faire n'importe quoi pour tout refaire ensuite
 
Si le design doc avec le code qui l'accompagne n'est pas compréhensible par quelqu'un qui n'a jamais vu le projet alors le truc est impossible à maintenir (on a tous redécouvert les subtilités de son propre code 3 mois après l'avoir fini )
 
J'entends que ça n'est pas faisable partout (genre si la boite a 5 developpeurs en tout et pour tout c'est débile) mais pour une boite du CAC / S&P500 / CSI 300 / un ministère c'est clairement nécessaire de se professionnaliser à ce niveau là
 
Et pour revenir au sujet payer convenablement ses devs fraîchement convertis au vibe coding

Un article intéressant  
 
 
https://www.radiofrance.fr/francecu [...] ie-9235952

 
Dans un pays étato-consumeriste ultra redistributif ou la grande majorité de la population est mise sous tutelle de classe et bloquée sous un plafond de verre.
 
Wokay  

J'ai de plus en plus de mal avec les sociologue. Ces gens sont tellement loin de la réalité souvent.... Déjà je pense que je ne crois pas au concept de classe sociale en fait.

C'est leurs retraites qui sont beaucoup trop grosses. Il faut les baisser beaucoup et baisser B (cotisations patronales) de la même chose.

Le taux de remplacement réel des fonctionnaires est le même que celui des retraités du privé. Leur retraite n'est pas plus grosse que les autres retraites.

Elles sont beaucoup trop grosses par rapport à la masse salariale des cotisants (d'où les taux de cotisation absurdes).

Ben oui bizarrement quand tu réduis drastiquement ta masse salariale pour la reverser dans le privé, après y'a moins de monde pour cotiser, c'est très étrange

 
 
La majeure partie du patrimoine des français est issue de l'héritage et des donations.
 
Dès lors tu sais que l'ascenseur social est niqué.