Merci pour ta franchise dans cette vidéo, ce n'est pas facile de se remettre en question. Il y a tellement de personnes qui se prennent pour des stars alors que c'est bien le travail d'équipe qui permet de réussir. Quand quelque chose ne va pas, commençons déjà par se remettre en question avant de chercher un responsable. J'aime bien l'angle que tu as pris avec ton exemple du marketing qui change toujours d'avis, c'est dur à vivre, pour eux aussi, mais c'est mieux de changer et d'obtenir un succès, plutôt que de planter tout l'équipe avec des erreurs de stratégie. Bravo encore pour cette vidéo !
@@33845652145 "Faut leur expliquer que sans les commerciaux ce serait zéro" -> Bon sens paysan. Je valide. Le gros du taff, c'est de vendre à des humains sur le marché global.
Je suis sincèrement désolé, mais vous vous trompez : un succès est toujours attribué à une équipe, mais c'est une convention sociale qui ne reflète pas la réalité. Que ce soit au football ou en programmation, le collectif n'est jamais l'élément déterminent d'une victoire. Prenons l'exemple de Lilian Thuram, au poste de défenseur qui marque un but en driblant sur toute la longueur du terrain ! Où est le mérite de l'équipe ? Ne cherchez pas trop longtemps. En informatique, c'est pareil ! Des gens qui ne développent pas, ont traduit les méthodes de production industrielle éprouvées, à savoir la répartition de charge, la décomposition ultime des cycles de production, pour confier des tâches désincarnées, comme sur les chaines de montage, et ainsi, en multipliant les amortisseurs de pression, optimiser sur le papier le temps de production. Une théorie dont on peut aisément démonter qu'elle est contre-productive, et qu'elle nivelle par le bas, la créativité et l'implication individuelle. Car pour qu'une initiative innovante puisse prendre forme, il faut de la liberté d'action. J'ai déjà vu des équipes de 10 bien pyramidales, avec à son sommet, un flan que personne n'osait remettre en question, faire réaliser une usine à gaz, alors qu'un seul développeur pouvait réaliser une solution couvrant le besoin dans son intégralité et éviter de redévelopper le fil à couper le beurre.
@@GIRARDINF Merci pour votre retour, mais je maintiens ma position. Le code est un sport d'équipe. Si votre modèle est Lilian Thuram qui joue tout seul sur un terrain de foot, sachez que c'est un acte remarquable, mais qu'il ne pourrait pas tenir les 90 minutes du match. C'est pareil pour vous, ne faites pas des échappés 8h par jour, 5 jours par semaine. Vous allez vous épuiser même si vous êtes exceptionnel. Reposez-vous sur votre équipe, cela fera du bien à tout le monde.
@@codeursenior je n'ai pas d'équipe, cela limite mes options. Et pour être honnête jusqu'au bout, quand cela arrive, je me heurte le plus souvent à un conformisme déroutant et incompatible avec la créativité qui me motive dans mon emploi. Donc à défaut de pouvoir compter sur autrui, et pour ne pas m'épuiser éternellement, comme vous le dites si bien, j'ai aiguisé mon esprit, pour trouver des solutions auxquelles en général personnes ne pensent. Classification souple depuis des dictionnaires de données externalisée. Externalisation des processus de traitement sous forme de logigramme interprété, quand ceux-ci dépendent de scénarios clients. Framework privé dédié à d'édition de logiciel, ce qui uniformise la programmation et recentre le développement sur le sujet et plus sur les "à côtés". Remplacement du code lié au respect des spécificités du métier par un moteur de causalité universel. J'ai aussi été formateur, et cela permet de bien comprendre que nous ne sommes pas tous égaux. Quoiqu'il en soit, compter sur les autres est le meilleur moyen de trouver un autre responsable que soi pour les échecs.
Votre clarté et honnêteté sur vos expériences sont la meilleure pédagogie convaincante qui se connecte directement aux neurones, à l'envie et la volonté de s'améliorer..MERCI encore 👍👍👏
Merci Simon sache que ton retour nous est précieux. Je suis dev officiellement sur le marché depuis 2 ans (actuellement en poste) et ça permet de se remettre en question. Je suis rassuré de me reconnaitre que très peu dans ce que tu as décris mais ça permet de travailler ces points. Je bosse actuellement avec une dette colossale de legacy et il m'a fallu des mois pour comprendre que ça n'allait pas se résoudre en 3 mois...
Merci pour ton retour. Tant mieux si tu ne te reconnais pas dans les points abordés, c'est bon signe. Bon courage pour ton refactoring, cela fait 24 mois que j'y suis et devrait avoir quasi fini d'ici à 1 an !
Je suis designer et j'adorerais bosser avec des développeurs comme toi. Désormais lorsque j'intègre une équipe, ma première demande est de rencontrer les devs. Merci pour cette vidéo!
Ce qui m'a le plus marqué c'est "la vraie qualité d'un code c'est la facilité à le changer" Je suis programmeur dans un pti studio indé et j'ai été confronté à des contraintes de temps très courtes pour implémenter du code dans un jeu dont le design était pas fini et qui changeait en cours de route. J'ai appris ça par la force des choses : j'avais pas le temps de bien coder mais coder en dur m'enchaînait jour après jours vers une réfacto du démon
Pour avoir travaillé avec beaucoup de dev et moi même devellopé (des libs de calculs), je pense qu'une des différences entre les bon et les débutants c'est la connaissance/ l'intérêt pour le métier qui justifie le dev.
Je me suis lancé en Freelance, et je confirme que les commerciaux ne font absolument rien. Ce n'a jamais été une problématique de faire leur taff lorsque je me suis mis à mon compte, le plus dur reste de pouvoir tout caser dans son planning sans que cela empêche de faire des boulots à réel valeur ajouté.
C'est assez vrai de manière générale, avec l'expérience on apprends a réfléchir d'abord et agir ensuite, mais ça dépend aussi de sur quoi on travail, parfois avec des codes expérimentaux ou qu'on ne fait pas souvent, c'est d'abord le code, on expérimente un peu, puis ensuite on réfléchie a tout ce qui ne va pas pour mieux repenser le code par la suite.
Merci, je commence un peu le code, je me suis vite rendu compte que le portable et UA-cam sont à bannir, même la musique, sauf si elle est uniquement instrumentale, soft genre je suis tombé sur une playliste coding sur Spotify... qui est juste parfaite pour ça. Je me rends compte aussi à quel point il faut essayer de faire du code le plus simple et limpide qui soit, après je ne suis qu'au touuuuuut début. En tout cas, je vais suivre la chaîne pour les conseils
Moi j'ai une règle perso, la musique c'est bien quand je fais du refactoring, quand j'ai besoin de faire une longue phase ou je relis au propre le code, et reprends ce qui ne va pas, souvent c'est plutôt long mais ça demande pas un énorme effort de concentration (surtout quand on connais bien le langage avec lequel on bosse, on sait instinctivement quoi utiliser pour remettre au propre tel ou tel chose), donc une petite musique en fond chill (volume pas trop fort) c'est cool, on fait les tests, on vérifie qu'on a rien cassé etc... et on passe à la suite etc... En revanche quand il y a vraiment besoin de ce concentrer, je coupe la musique, ça reste une distraction quand il y a besoin de réfléchir, même si le volume est faible, vaut mieux être à 100% dans ce genre de cas, aucune distraction extérieure c'est le mieux.
Bonjour merci de tes vidéos. Pour ma part je sors d’un bootcamp sous react. Je prends conscience que j’ai encore un step à passer. J’entends que mon code semble fonctionnel, mais je peux améliorer. Oui comme tu le fais entendre rendre propre des fondamentaux avant d’essayer d’autres horizons. Et dans une autre vidéo tu parles d’entretenir des acquis et progresser en faisant des exercices quotidiennement. Pour moi c’est les algos. Enfin merci de ton retour d’expérience
Au top, merci pour ton partage d'expérience. Effectivement, plus tu prends du temps à construire et élargir la base, les fondamentaux, plus tu pourras te construire une pyramide de compétence haute !
Par rapport au syndrome Jimmy Neutron et au syndrome de la fille à la robe rouge, les deux dépendent beaucoup de l’équipe que tu vas intégrer. Personnellement, quand j’ai commencé à intégrer une équipe de développement en milieu pro, j’avais une connaissance théorique assez poussée du C++, et notamment de ses dernières moutures (C++14 à l’époque, pour les connaisseurs). Mon code était donc un code canonique des derniers standards. Quand j’ai intégré cette équipe, je codais comme ça parce que tous les projets perso que j’avais fais étaient de ce style, c’était pas pour faire genre. Là où je dis que ça dépend de l’équipe, c’est que plutôt que de me dire "non mais nous on fait à l’ancienne, adapte toi", le reste de mon équipe a été très intéressé par cette veille technologique, j’ai été en mesure de leur expliquer les raisons technique du choix de ces méthodes vis-à-vis de la vieille école (la plupart étant lié à une réduction de comportements indéfinis ou d’une gestion mémoire plus resistantes aux exceptions (RAII, smart pointer, mutex lock etc.), mais il y avait aussi des méthodes liées à l’amélioration de la lisibilité du code (range-based for, programmation d’avantage déclarative), des techniques pour produire des messages d’erreurs plus courts et compréhensibles en cas d’erreur de compilation (SFINAE) ou même des techniques qui pouvaient augmenter grandement les performances (move semantic, perfect forwarding, static dispatch, compile time evaluation)). 5 ans après, j’étais devenu le référent technique C++, tous n’a pas été pris de ce que je faisais bien évidemment, et moi-même j’ai évolué sur ma pratique, je l’ai peaufinée, mais aujourd’hui plus personne ne code à l’ancienne (à la C) dans la boîte, le manager, qui a un bon bagage technique m’a missionné de former tous les devs aux techniques que j’avais introduites qui étaient communément encensées et le nombre de bugs liés à des problèmes mémoires (double free, perte de mémoire ou même seg fault) s’est réduit drastiquement et la plupart du temps, quand on en découvre, c’est sur du code legacy justement. Continuant de faire ma veille technologique, j’ai aussi été un lobbyiste pour adopter le rust pour remplacer le C++ (pour pleins de raisons diverses, les principales étant la facilité d’apprentissage pour les nouveaux devs et les sécurités de code que ce langage introduit vis-à-vis du C++), maintenant que je suis parti de la boîte, j’apprends qu’ils envisagent de s’y mettre. Donc ici, vis à vis de ce que tu dis, ce que j’ai introduit était en parti dans le but d’améliorer la lisibilité du code, et pour le rust, il s’agissait d’adopter un langage qui soit bien plus simple à apprendre que le C++ (qui est, je pense, un des langages les plus difficiles à maîtriser, plein de langages ont été créé précisément dans le but de faire un C++ plus simple comme le C#, le D, le go), mais dans l’absolu, tout ceci est complètement nouveau pour les anciens devs, qui à l’époque avaient donc du mal avec ce que je faisais, c’était trop différent de leur pratique, et apprendre un tout nouveau langage, qui certes s’inspire fortement du C++, mais qui est quand même très différent sur pleins de points, c’est même un stade au dessus de ce que tu dis être des mauvaises pratiques. Et pourtant, ce que j’ai fais a réellement apporté un plus à l’équipe, une fois formée. Donc être ouvert aux nouveautés c’est quand même important, mais surtout il faut savoir justifier pourquoi et évidemment, j’ai conscience que dans d’autres entreprises, ça ne se serait pas forcément passé ainsi.
Je ne trouve pas le C# si simple que cela. J'ai été obligé de rétrograder du code pour des collègues et je peux te dire que j'étais le seul avec un consultant externe que l'on déplaçait depuis 20 ans qui savait de mémoire faire les différences entre les versions de C#. J'ai remarqué deux tendances dans le domaine premièrement, il y a les métiers de la gestions administrateur réseau, DBA, autres. Puis, il y a les faux informaticiens comme ceux qui prétend que de connaître SAP HANA demande 4 ans d'expérience et qu'ils méritent plus cher ou les autres qui sont des statisticiens, mais utilise un logiciel de calcul quand même pour convaincre les autres qu'il ne faut pas faire d'étude pour devenir pro des mathématiques. Les développeurs sont des bouches-trous, tu es là pour écrire du code et selon le niveau de complexité que tu veux imposer pour faire évoluer ton système, tu risques plus ou moins de perdre ton emploi parce que tout ce que l'on veut de toi, c'est des trucs à présenter au conseil d'administration pour montrer que l'on fait quelque chose et qu'ils ne savant pas lire une documentation technique. Je ne suis pas capable de coder à mon niveau dans une entreprise, ils ne respectent pas suffisamment les diplômes et ce n'est pas une question de talent, j'aimerais bien que la personne consulte le PMBOK, le SWEBOK et maîtrise quelques méthodes formelles. Je ne veux pas rigoler, mais on ne m'a pas passé en entrevue pour une expérience sur un projet open source dont j'ai contribué. Ils avaient une liste d'entreprises valables dans leur cas, mais je ne peux pas avoir l'expérience de mon propre code dans cette industrie et je dois les respecter. Je travaille mais ne me demande pas d'implication si je veux une bonne situation financière, c'est par mes propres moyens et non comme employé.
@@BelleMorue je ne dis pas qu'ils ont réussi à faire un langage plus simple que c++, je dis que c'était leur but à la base. Je ne connais pas C# je serai bien incapable de te dire si c'est le cas où non. Cela dit, C++ a l'air universellement reconnu comme un langage trop complexe.
Après, les nouveautés, quand on fait du C++... c'est pas exactement des nouveautés ! Particulièrement à l'époque dont tu parle. Le standard prend son temps pour évoluer. Rien à voir avec les ruées qu'on pouvait constater à la même époque dans le monde de JavaScript. D'ailleurs, quand C++11 est devenu le nouveau standard, ça faisait 8 ans qu'il n'y avait pas eu de mises à jours majeures. En ce qui concerne Rust, à titre personnel, justement, j'attend encore quelques années avant de _peut-être_ m'y mettre. Il y a encore trop de controverse sur le sujet, et je préfère attendre 1) que la poussière tombe, 2) que le langage prenne en maturité (ce dernier point ne pouvant se faire qu'avec suffisament d'utilisateurs et de temps investi). Donc pour le moment, je continuerai de développer mes applications et mes sites webs en C++ !
@@Harold046 Les nouveautés en C++ ne sont pas exactement des nouveautés ? Alors, comme je le sous-entendais, les devs de ma boîte codaient "à la C", donc n’utilisaient pas les fonctionnalités de C++11, donc pas de lambda, pas de move semantic, pas de templates variadique, pas de range-based loop, pas de constexpr, pas d’auto, pas d’header type_traits (et donc pas de SFINAE), pas de mutex standard (et donc pas de lock_guard), pas de thread standard, pas d’assertion statique, pas d’enum class, pas de smart pointer utile (auto_ptr était une catastrophe), pas de regex standard… Toutes ces fonctionnalités changent fondamentalement la façon de coder en C++ ce qui rend du code C++11 drastiquement différent d’un code C++03. Le C++11 a mis longtemps à venir parce que beaucoup de choses était prévu à la base, les concepts notamment étaient déjà prévu en C++11 mais on été retirés, les concepts changent aussi beaucoup de choses en méta-programmation en C++. De manière générale, C++20 est une mise à jour au moins aussi importante que C++11 l’a été en son temps avec l’introduction des concepts, les contraintes, les coroutines et des modules.
Ce n'est peut-être pas grand chose mais je tiens a te remercier pour la qualité de tes conseils ainsi que des recommandations littéraire surtout en ce qui concerne la productivité ! Bon courage a toi en ce qui concerne le coaching de vos futurs recrue ainsi que tes futurs projets
Si ton senior n'était pas content de tes imports en cascade, il aurait dû installer un linter comme Prettier qui t'aurait évité ça. C'est son boulot d'encadrer les juniors et même les seniors avec les bons outils de contrôle de code. Si un de mes juniors committe du code comme ça je considère que c'est pas de leur faute mais de la mienne
Hello, je salue votre approche, elle peut sauver des équipes et des projets. 💪 👉 Tous les aspirants Tech Lead doivent lire ça : "Si un de mes juniors committe du code comme ça je considère que c'est pas de leur faute mais de la mienne"
Cette remarque est dépendante du contexte. Il faut un minimum que les développeurs soient responsabilisés et tout n'incombe pas au tech. lead. J'ai vu de réelles mentalités à deconstruire avec des devs qui ne relisaient même pas leur code avant d'envoyer en review. Les outils comme prettier/eslint sont d'une aide très précieuse mais certains concepts sont juste trop difficiles à contrôler via ces outils, il y a une limite. Selon le niveau de connaissance/ bande passante du tech. lead, certaines choses passent à la trappe, personne n'est infaillible. Voilà, je voulais juste tempérer un peu les propos car la réalité est très souvent nuancée.
@@monome9992 Tout ne repose pas sur les épaules du Tech Lead, mais j'aime bien faire comme si. Cela me permet de garder le contrôle sur ce qu'il se passe. Quelqu'un livre n'importe quoi ? Pourquoi ne pas organiser un workshop pour progresser sur ce point ? C'est le genre de croyance fausse que je trouve utile.
Haha je me suis dis pareil direct. En tant que Tech Lead j'ai mis des jobs de CI/CD bien strict et tant que ça ne passe pas, le développeur dois retravailler son code (lint, type checking, tests unitaires, build,...)
Par rapport a la relation au marketing qui change tout le temp d'avis, tant qu'on te demande pas de modifié le code en cours de sprint ca me va. Le PO est le coordinateur et c'est son rôle de refuser. Dans les plus petites entreprises, il n'y a pas toujours de PO qui calme les ardeurs du marketing.
Merci beaucoup Simon c'est vraiment interessant tes partages d'expériences. La productivité est capitale sinon on laisse place à la baisse de performance.
Bonsoir Professeur, vraiment merci infiniment pour ce beau tuto. Je suis très heureux de vous retrouver. Merci encore une foie de plus pour votre partage du savoir.
Attention tout de même aux revirement du marketing : car si tu as tout fait pour rester KISS et YAGNI ( pour sortir ton MVP au plus vite) alors ton code ne sera pas forcément robuste aux changements 😅
C'est très perturbant de voir que les habitudes décrites ici correspondent à ce qui est la norme dans mon entreprise au niveau du comportement des seniors (excepté pour la robe rouge)...
Merci pour cette publication, que j'ai trouvé très pertinente, comme souvent dans ton contenu. Merci également de nous partager tes expériences et références. Bravo!
Hello, intéressant. J’ai deux questions : - vous travaillez en deep work de 6h à midi c’est bien ça ? - est ce que vous avez besoin de vous synchroniser avec d’autres personnes ? Si oui, quand le faites vous ?
@@codeursenior de 6 h vers 13-14 heure ensuite je peux faire les tâches administratives et la communication l'après midi. je privilégie les communications asynchrones et j'ai banni le mot ''urgence''. c'est vrai qu'en ce moment je travaille seul. en début d'année, je vais commencer à déposer mes travaux Open Source. je vais donc possiblement rentrer en contact avec des personnes du monde entier. de ce fait, il n'y a pas trop d'horaires à respecter. comme le dit la philosophie Zen, ne faire qu'une seule chose à la fois et le faire pleinement. sortir du brouhaha de l'hyper-communication et faire la tâche que l'on s'est donné. pour finir, sortir de l'hyper-utilisation de technologies peu stables.
Merci pour ta vidéo, je souhaiterai devenir développeur, comment le devenir ? Ou se former ? Quelles écoles et centre de formation ? Les qualifications suite aux formations sont-elles reconnues par les entreprises ... ? Ce serait un thème de vidéo qui m'intéresserai.
Hello, merci pour tes questions. Je n'aborde généralement pas ces sujets qui sont très "tôt" dans le parcours d'un développeur. J'ai tout de même ajouté tes questions à ma liste d'idée de prochaines vidéos possibles. Bon apprentissage ! P.S : Pas besoin de diplôme pour commencer à coder, Internet est ton école pour le moment.
Pour ma part, je commence ma reconversion au centre de formation Arinfo. C'est une formation adulte, niveau bac+2 en sortie, certification reconnue par l'état. Si cela peut vous aider...
Bonjour, je viens témoigner moi aussi, j'ai pour ma part commencé une formation de développeur web et Web Mobile pour le compte de Créative Formation, ils proposent cette formation un peu partout dans les villes moyennes(Caen, Le Mans, ect); pour ce qui est de commencer, les cours gratuits d'OpenClassRooms m'ont fournis une bosse base; Je vous conseille fortement de commencer dans votre coin et de ne pas attendre de vous retrouver en formation, ce sont des formation à courte durée où l'on à pas forcément le temps de bien s'attarder sur des notions-clés du développement. Commencez chez vous, à votre rythme, rentabilisez le temps que vous avez aujourd'hui pour être plus à votre aise une fois en formation (c'est comme sa que j'ai fait et je suis plutôt à l'aise pour le moment (enfin si j'arrête un jour de m'imposer l'apprentissage des diverses techno en plus de mon programme de formation xd))
Merci Simon pour cette vidéo très instructive. Je viens de finir une formation de dev web et je suis en recherche d’emploi. Tes conseils vont m’être utile.
Salut mec j'espère que tu es au top ,bref j'ai beaucoup question te poser notamment node JS et premièrement j'ai envi de m'assurer que tu me repends dabors 😂
Je suis ingénieur mais pas développeur, loin de la, mais tout les conseils de cette vidéos sont largement transposables à d'autres positions de création/ingénierie. Superbe vidéo
4:06 je me souviens du code shell cryptique que je voyais sur des blogs il y a une dizaine d'années. Je me sentais nul parce que je ne comprenais pas rapidement ce que faisait ce code. Maintenant, je me dis que je n'aurais pas aimé travailler avec ceux qui écrivaient ces commandes. Dans le même genre, il y a les solutions les mieux notées des puzzles codingame où le code est le plus concis possible. C'est dommage que la plateforme mette en avant ces solutions très éloignées du code professionnel.
Le point sur marketing c'est peut-être aussi un problème de formation, comme le point 1 d'ailleurs... Ne pas comprendre comment fonctionne une entreprise et qu'elle s'insère dans un environnement concurrentiel, c'est un vrai problème qui dépasse le soft skill à mon avis. On embauche pas des devs pour le plaisir mais répondre à des besoins. Et ça se découvre avec le temps, le marché évolue aussi...
En tant que freelance, n'est-ce pas une perte de temps et surtout d'argent d'accepter que le marketing change d'avis ? Si la demande est accompagnée d'une compensation financière, je n'ai rien à dire, mais s'il faut assumer sois même, je ne suis pas d'accord avec l'argument du challenge. Je reste cependant enclin à être flexible pour d'éventuels ajustements, mais ça doit rester raisonnable à mon avis.
En tant que freelance, tu chiffres ton activité. Si tu ne le fais pas ou si tu ne sais pas le faire, tu es un mauvais freelance. Le jeu c est de vendre sa compétence en jour travaillé et marger sur cette valeur. Le changement fait partie de la facture.
@@fredericlossignol3874 En tant que freelance, tu fournis surtout un travail et du temps que tu ne veux pas gâcher. La règle est simple : vie = temps = argent. Donc oui mon temps est précieux et je le donne pas à volonté.
C'est sûr que le développeur senior n'a pas grand-chose à faire sur une chaîne qui aide à devenir développeur senior. Puisqu'il est déjà développeur senior. C'est pas une question de putacliquage, c'est seulement logique. Pour le développeur junior, je trouve que les conseils sont pertinents.
Ahhhhh, pilule rouge, bien évidemment. 😄 Tellement mythique cette scène. Au passage, je ne sais pas si c'est toi qui fait le montage, mais tes cuts sont propres. On a presque l'impression que tu as fait ton enregistrement d'une traite. 👌🏽
@@dominiquetalis1516 Bien joué team #PiluleRouge ! Ecoute merci, c'est la première fois que quelqu'un me dit que le montage est propre. 😂 Pour le moment je fait encore le montage à la main, j'envisage de sous-traiter cela en 2024. Bon code à toi !
éviter de vouloir bien faire les choses, quand on est inexpérimenté on ne sait pas encore que ce qui n'est pas fait à la première livraison sera refacturé le double en corrections ultérieures 😅
Ah le légendaire x2 sur les tutos m'a pire manie ça, j'ai regarder ta vidéo en normal là par contre, faut bien faire une petite pause entre deux scripts.
Salut merci pour la vidéo, Quesiton : Reussir le test du refactoring présenté dans la vidéo comme un changement d'avis du marketing et respecté le principe YAGNI n'es pas contradictoire ? Comment faire du code capable de s'adapter quand on s'interdit de partir sur un design pattern aprés 3 else if ? Merci (question ouverte à tous).
Mon avis : C'est une aussi une question de bon sens et d'expérience. Imaginons tu as un système COEUR + modules A/B/C (module = fonctionnalité genre envoi de SMS ou autre) Si ton "else / if" permet de charger tes modules en dur dans le code, ok tu as 3 modules donc un système IF/ELSE suffit (ie
Hello, est-ce que vous travaillez en entreprise ou freelance ? Je n'ai pas progressé en code pendant toutes mes études car nous étions coincé dans "tutorial land".
@@serge_amon C'est très bien Udemy. Vous pourriez vous trouver un projet personnel avec quelques utilisateurs ou travailler avec d'autres développeurs en apprentissage pour vous forcer à vous confronter à plus de feedback. Bon apprentissage et bon code à vous !
Ben ouhe Simon il faut savoir « se vendre » et avoir la tchache mais je ne suis pas plus avancée pour autant et qu’au début de ma reconversion et je ne sais pas si j’y vais ou je passe à autre chose et pourtant je suis motivée.
Hello, je préparer une "grosse vidéo" de 90 minutes qui ne sera pas sur UA-cam (le format ne s'y prête pas) ou j'essayerai de vous donner une sorte de roadmap qui a marché pour mes élèves et moi-même dans leur reconversion. A bientôt j'espère, ne vous découragez pas... codez !
cela serait possible de rentrer plus dans le détail plus palpable? , cela fais 2 ans que je suis développeur en entreprise je n'ai jamais rencontré les problèmes exprimé ici même les première semaines. Est il possible d'axer sur des choses concrète qui nous permettrait de mieux nous définir dans notre travail. exemple: quel approche va prendre un senior pour la sécurisation de plusieurs key , comment un senior exploite le MultiThreading pour optimiser le plus possible l'efficience du logiciel. Quel sont les pratiques qu'il mettra systématiquement en place pour minimiser les appel externes et recycler le plus possible les données pour éviter de nouveau appel. Je me considère junior car pour moi ces questions ouvre plusieurs choix la ou un senior devrais ne voir qu'une seul réponse toujours valable est applicable ( il y a plusieurs chemin pour arriver à destination mais un seul sera le plus court)
Je me permets une remarque : en développement, et encore plus en ingénierie informatique, il y a rarement une solution claire et évidente, parce que la solution "optimale" dépends de nombreux facteurs contextuels: expérience et compétences de l'équipe, état de la base de code, langage et technologies utilisées, contraintes de fiabilité, de performances, d'évolutivité, ... En fait, c'est de la résolution de problème complexe, et pour ça ya globalement une seule méthode : essai et erreur jusqu'à que ca marche. Une différence entre un junior et un sénior dans ce cas, c'est que en général le sénior est plus cultivé, a déjà été confronté à de nombreux problèmes, et souvent des problèmes similaires, et donc il a une meilleur idée de là où il faut chercher en premier, et aussi une plus grande capacité d'analyse. Par exemple dans le cas du multithreading pour optimiser l'efficience du logiciel, un sénior répondrait probablement : aucune idée sans plus d'info. D'autant que ça dépends comment on compte l'efficience, mais en général un logiciel multithread est moins efficient qu'un logiciel monothread, parce qu'il y a un coût supplémentaire en temps et en mémoire pour orchestrer les threads.
@@felixbertoni merci beaucoup pour votre commentaire au contraire il faut que plus de gens comme vous se permettent de répondre , ça me donne déjà beaucoup d’éclaircie notamment sur l’approche, ça corrobore ma façon de faire et me rassure un peu de pas être dans la mauvaise voie. Désolé pour le manque de contexte l’idée été de pose de grand point d’interrogation global. Effectivement j’ai une méthode empirique pour avancer dans une problématique. Cela me semblait être une mauvaise approche du fait de la perte de temps que cela génère mais vous me rassurez déjà beaucoup. En ce qui concerne la résolution de problème je vois exactement ce que vous voulez dire ahah par fois on voit un soucis qui sort de nul part et on sait le résoudre presque naturellement sans avoir besoin de chercher c’est déroutant. Au plaisir d’échanger merci encore pour la réponse
Pour les commentaires, j’aurais tendance à attaquer la « diète » la dessus. De mon expérience cela crée assez peu de valeur. Par contre être tenace sur les defect, bien joué, même si parfois une pause est salvatrice. Bon code !
Ce que je remarque le plus avec les développeurs moins expérimentés, c'est un manque de respect de l'architecture. Lorsqu'ils codent , on dirait qu' ils n'arrivent pas s'imprégner du style de programmation de l'ensemble du code. Je n'ai pas d'appréciation, je dois être difficile à aider parce que c'est rare que l'on vient m'expliquer la technique, on me donne un design et je dois commencer à valider à la conception. Si la conception ne fonctionne pas, j'ai des maux de ventre parce que faire bouger un architecte, il faut plus que des mots. Tu dois le montrer avec un contre exemple où cela ne fonctionne pas. Il faut avoir une solution avant d'exposer un problème. Ce n'est pas un client, tu as gorille de l'informatique devant toi et il va poser des questions exigeantes qui demandent de penser plus rapidement que tu le fais normalement et bien le faire. Biensure, ils vont trouver un truc génial bien meilleur que ta solution, mais ils vont savoir que tu comprends bien leur idées.
Si tu consultes un Grevisse (par exemple) tu verras que "chez", selon les puristes, ne doit s'employer qu'avant un nom de personne. On dit donc chez Leroy-Merlin, chez Darty, mais À Atos.
@@codeursenior Pour l'instant je sais pas faire. Je leur montre la source d'un jeu de pong, quand ils découvrent le niveau à atteindre ils renoncent à tout jamais à devenir programmeurs.
Franchement vu l'historique d'Atos est comment il traite leur consultant c'est pas très glorieux d'en parler c'est tout sauf une référence Atos. De plus pas étonnant que tu es été choisis en tant que jeune formateur le principe de cette compagnie étant de faire un max d'argent sur les TJM concernant les juniors. Je parlerais même pas d'être le premier Junior de France en tant que formateur Java ça reste à prouver et je ne vois pas l'intérêt de mettre ça en avant. Reste toi même tu es encore jeune !
"Je parlerais même pas d'être le premier Junior de France en tant que formateur Java ça reste à prouver" La phrase exacte "un des plus jeune formateur JavaScript de France". Je peux le prouver avec mon ordre de mission de l'époque quand j'avais 26 ans. Du coup : Java => JavaScript Premier => Plus jeune
Je suis un débutant sur l'informatique et j'étudie à l'université de Douala au Cameroun, quel conseil dois-je ou pouvez vous me donner pour être un développeur professionnel c'est AHAMAT CHAIBO
Si j'ai un conseil à te donner, c'est de d'abord te poser une question essentielle : je veux devenir développeur pour quoi ? Quand tu aura répondu à cette question, tu pourras choisir un langage, même s'il est en dehors de ce que tu apprends à l'université, qui correspond à tes attentes. Ensuite, le plus important sera de rester focus sur ce langage afin de, dans un premier temps, comprendre les fondamentaux (variables, types, boucles, structure de données, algorithmie, ...) de la programmation, et ensuite, maîtriser la syntaxe du langage. Dernier conseil, tu vas souvent te confronter à des problèmes qui te semble insolvables. Ne baisse pas les bras, à ce moment-là. C'est dans la difficulté, qu'on apprend réellement à programmer. Bon courage à toi. 👋🏽
Mon conseil serait de commencer par les bases : le C par exemple (ou mieux l'asm 🥳), avant de se tourner vers les languages plus haut niveaux (oop, script, bytecode, etc.) 2eme conseil s'intéresser au monde libre, open source, voire y contribuer. Cela permet de voir du beau code et d'apprendre les bases dans un environnement "pédagogique" (c'était le cas des vieilles distros linux qui mtn ont tendance à un peu trop se windowiser) le tout pour gratuit.
Voila pourquoi faire une ecole d’ingénieur cest tres avantageux parce quon ty apprends la plus part de ce que tu dis dans cette video… excellents conseils
Si seulement ;) Pour fréquenter beaucoup d'ingés à différents niveaux d'expérience, les points cruciaux énoncés dans la vidéo sont rarement compris de façon intuitive, et créent parfois carrément un rejet. C'est d'ailleurs particulièrement commun avec les français dont le sens commercial est de base très mauvais par rapport à celui de l'américain ou du canadien moyen, sans parler du complexe de supériorité école d'ingé assez dévastateur.
Dans le même style que Jimmy Neutron, t'as l'effet Dunnning Kruger qui consiste à sur estimer ses capacités. Puis, avec l'expérience tu te rends compte qu'il te reste beaucoup à apprendre
5/10 ya des choses interessantes dans la vidéo, un retour d'expérience assez bon dans l'ensemble mais je trouve votre communication assez mauvaise car vous faites trop de jugement précoce
dans les jeux vidéo les filles en robe rouge sont une catastrophe socio-économique neo: hé regarde les derniers unity unreal godot morpheus: ON CODE POUR SMARTPHONE BORDEL
Oui enfin c'est juste pour impressionner les recruteurs ou bosser genre a Google. Arrivé en Mission ça utilise des solutions gratuites ou qui date car budget serré 😅
c'est dingue des mots english dans chaque phrase c'est pas possible de parler vraiment french ? parce que parler franglais à tout bout de champ, ça devient vite boring
Les informaticiens ont certainement l'anglais un peu facile. la plupart des docs ou des ouvrages intéresants sont en anglais de nos jours.. pas souvent traduits
Ca dépend du domaine. Dans des boites ou la R&D est primordiale, genre OpenAI ou en FinTech, les ingénieurs, qui ont souvent un doctorat, utilisent beaucoup leurs hard skills.
Désolé mais apprendre à faire une présentation, ce n'est pas un softskill. C'est un hardskill qui n'est pas purement IT, mais pas un softskill. Les softskills sont tout ce qui a trait à ta personnalité globalement.
Merci pour ta franchise dans cette vidéo, ce n'est pas facile de se remettre en question.
Il y a tellement de personnes qui se prennent pour des stars alors que c'est bien le travail d'équipe qui permet de réussir.
Quand quelque chose ne va pas, commençons déjà par se remettre en question avant de chercher un responsable.
J'aime bien l'angle que tu as pris avec ton exemple du marketing qui change toujours d'avis, c'est dur à vivre, pour eux aussi, mais c'est mieux de changer et d'obtenir un succès, plutôt que de planter tout l'équipe avec des erreurs de stratégie.
Bravo encore pour cette vidéo !
Hello, tout à fait. Les frustrations de court-terme sont souvent les succès de demain. 👍
@@33845652145 "Faut leur expliquer que sans les commerciaux ce serait zéro" -> Bon sens paysan. Je valide. Le gros du taff, c'est de vendre à des humains sur le marché global.
Je suis sincèrement désolé, mais vous vous trompez : un succès est toujours attribué à une équipe, mais c'est une convention sociale qui ne reflète pas la réalité. Que ce soit au football ou en programmation, le collectif n'est jamais l'élément déterminent d'une victoire. Prenons l'exemple de Lilian Thuram, au poste de défenseur qui marque un but en driblant sur toute la longueur du terrain ! Où est le mérite de l'équipe ? Ne cherchez pas trop longtemps.
En informatique, c'est pareil ! Des gens qui ne développent pas, ont traduit les méthodes de production industrielle éprouvées, à savoir la répartition de charge, la décomposition ultime des cycles de production, pour confier des tâches désincarnées, comme sur les chaines de montage, et ainsi, en multipliant les amortisseurs de pression, optimiser sur le papier le temps de production. Une théorie dont on peut aisément démonter qu'elle est contre-productive, et qu'elle nivelle par le bas, la créativité et l'implication individuelle. Car pour qu'une initiative innovante puisse prendre forme, il faut de la liberté d'action.
J'ai déjà vu des équipes de 10 bien pyramidales, avec à son sommet, un flan que personne n'osait remettre en question, faire réaliser une usine à gaz, alors qu'un seul développeur pouvait réaliser une solution couvrant le besoin dans son intégralité et éviter de redévelopper le fil à couper le beurre.
@@GIRARDINF Merci pour votre retour, mais je maintiens ma position. Le code est un sport d'équipe. Si votre modèle est Lilian Thuram qui joue tout seul sur un terrain de foot, sachez que c'est un acte remarquable, mais qu'il ne pourrait pas tenir les 90 minutes du match. C'est pareil pour vous, ne faites pas des échappés 8h par jour, 5 jours par semaine. Vous allez vous épuiser même si vous êtes exceptionnel. Reposez-vous sur votre équipe, cela fera du bien à tout le monde.
@@codeursenior je n'ai pas d'équipe, cela limite mes options. Et pour être honnête jusqu'au bout, quand cela arrive, je me heurte le plus souvent à un conformisme déroutant et incompatible avec la créativité qui me motive dans mon emploi. Donc à défaut de pouvoir compter sur autrui, et pour ne pas m'épuiser éternellement, comme vous le dites si bien, j'ai aiguisé mon esprit, pour trouver des solutions auxquelles en général personnes ne pensent. Classification souple depuis des dictionnaires de données externalisée. Externalisation des processus de traitement sous forme de logigramme interprété, quand ceux-ci dépendent de scénarios clients. Framework privé dédié à d'édition de logiciel, ce qui uniformise la programmation et recentre le développement sur le sujet et plus sur les "à côtés". Remplacement du code lié au respect des spécificités du métier par un moteur de causalité universel.
J'ai aussi été formateur, et cela permet de bien comprendre que nous ne sommes pas tous égaux. Quoiqu'il en soit, compter sur les autres est le meilleur moyen de trouver un autre responsable que soi pour les échecs.
Votre clarté et honnêteté sur vos expériences sont la meilleure pédagogie convaincante qui se connecte directement aux neurones, à l'envie et la volonté de s'améliorer..MERCI encore 👍👍👏
Au top, merci pour votre retour. Ne lâchez rien, passez massivement à l’action, et bon code senior à vous ! 👊
Je viens de te découvrir Simon, et sache que ton travail sur les soft skills a réellement payé car je t ai trouvé vraiment captivant
Merci Simon sache que ton retour nous est précieux. Je suis dev officiellement sur le marché depuis 2 ans (actuellement en poste) et ça permet de se remettre en question. Je suis rassuré de me reconnaitre que très peu dans ce que tu as décris mais ça permet de travailler ces points. Je bosse actuellement avec une dette colossale de legacy et il m'a fallu des mois pour comprendre que ça n'allait pas se résoudre en 3 mois...
Merci pour ton retour. Tant mieux si tu ne te reconnais pas dans les points abordés, c'est bon signe.
Bon courage pour ton refactoring, cela fait 24 mois que j'y suis et devrait avoir quasi fini d'ici à 1 an !
🤣@@codeursenior
Si ça se résoud un jour 😅
Je suis designer et j'adorerais bosser avec des développeurs comme toi. Désormais lorsque j'intègre une équipe, ma première demande est de rencontrer les devs. Merci pour cette vidéo!
Ce qui m'a le plus marqué c'est "la vraie qualité d'un code c'est la facilité à le changer"
Je suis programmeur dans un pti studio indé et j'ai été confronté à des contraintes de temps très courtes pour implémenter du code dans un jeu dont le design était pas fini et qui changeait en cours de route. J'ai appris ça par la force des choses : j'avais pas le temps de bien coder mais coder en dur m'enchaînait jour après jours vers une réfacto du démon
je suis dans le même cas xD c'est vraiment pas facile au début
Pour avoir travaillé avec beaucoup de dev et moi même devellopé (des libs de calculs), je pense qu'une des différences entre les bon et les débutants c'est la connaissance/ l'intérêt pour le métier qui justifie le dev.
ou tout simplement être un poil humble et savoir apprendre des vieux cons (séniors)
@@julienr8114 et avant d'être des vieux cons, c'était des jeunes donc ça prouve que l'on évolue 😂
Une des meilleures chaines sur l'apprentissage de la programmation. Merci pour tous tes conseils, papa Simon
Je me suis lancé en Freelance, et je confirme que les commerciaux ne font absolument rien.
Ce n'a jamais été une problématique de faire leur taff lorsque je me suis mis à mon compte, le plus dur reste de pouvoir tout caser dans son planning sans que cela empêche de faire des boulots à réel valeur ajouté.
Tout seul tu construis une belle cabane de jardin qu'à plusieurs ces abrutis , ils construisent une tour Eiffel !
Wow! Du vrai! J'ajouterais: un senior pense et code, un junior code et pense(souvent il pense à pourquoi son code est devenu un tel bordel).
C'est assez vrai de manière générale, avec l'expérience on apprends a réfléchir d'abord et agir ensuite, mais ça dépend aussi de sur quoi on travail, parfois avec des codes expérimentaux ou qu'on ne fait pas souvent, c'est d'abord le code, on expérimente un peu, puis ensuite on réfléchie a tout ce qui ne va pas pour mieux repenser le code par la suite.
Merci pour votre conseil
Merci, je commence un peu le code, je me suis vite rendu compte que le portable et UA-cam sont à bannir, même la musique, sauf si elle est uniquement instrumentale, soft genre je suis tombé sur une playliste coding sur Spotify... qui est juste parfaite pour ça.
Je me rends compte aussi à quel point il faut essayer de faire du code le plus simple et limpide qui soit, après je ne suis qu'au touuuuuut début.
En tout cas, je vais suivre la chaîne pour les conseils
Moi j'ai une règle perso, la musique c'est bien quand je fais du refactoring, quand j'ai besoin de faire une longue phase ou je relis au propre le code, et reprends ce qui ne va pas, souvent c'est plutôt long mais ça demande pas un énorme effort de concentration (surtout quand on connais bien le langage avec lequel on bosse, on sait instinctivement quoi utiliser pour remettre au propre tel ou tel chose), donc une petite musique en fond chill (volume pas trop fort) c'est cool, on fait les tests, on vérifie qu'on a rien cassé etc... et on passe à la suite etc...
En revanche quand il y a vraiment besoin de ce concentrer, je coupe la musique, ça reste une distraction quand il y a besoin de réfléchir, même si le volume est faible, vaut mieux être à 100% dans ce genre de cas, aucune distraction extérieure c'est le mieux.
Bonjour merci de tes vidéos. Pour ma part je sors d’un bootcamp sous react. Je prends conscience que j’ai encore un step à passer. J’entends que mon code semble fonctionnel, mais je peux améliorer. Oui comme tu le fais entendre rendre propre des fondamentaux avant d’essayer d’autres horizons. Et dans une autre vidéo tu parles d’entretenir des acquis et progresser en faisant des exercices quotidiennement. Pour moi c’est les algos. Enfin merci de ton retour d’expérience
Au top, merci pour ton partage d'expérience.
Effectivement, plus tu prends du temps à construire et élargir la base, les fondamentaux, plus tu pourras te construire une pyramide de compétence haute !
Par rapport au syndrome Jimmy Neutron et au syndrome de la fille à la robe rouge, les deux dépendent beaucoup de l’équipe que tu vas intégrer. Personnellement, quand j’ai commencé à intégrer une équipe de développement en milieu pro, j’avais une connaissance théorique assez poussée du C++, et notamment de ses dernières moutures (C++14 à l’époque, pour les connaisseurs). Mon code était donc un code canonique des derniers standards.
Quand j’ai intégré cette équipe, je codais comme ça parce que tous les projets perso que j’avais fais étaient de ce style, c’était pas pour faire genre. Là où je dis que ça dépend de l’équipe, c’est que plutôt que de me dire "non mais nous on fait à l’ancienne, adapte toi", le reste de mon équipe a été très intéressé par cette veille technologique, j’ai été en mesure de leur expliquer les raisons technique du choix de ces méthodes vis-à-vis de la vieille école (la plupart étant lié à une réduction de comportements indéfinis ou d’une gestion mémoire plus resistantes aux exceptions (RAII, smart pointer, mutex lock etc.), mais il y avait aussi des méthodes liées à l’amélioration de la lisibilité du code (range-based for, programmation d’avantage déclarative), des techniques pour produire des messages d’erreurs plus courts et compréhensibles en cas d’erreur de compilation (SFINAE) ou même des techniques qui pouvaient augmenter grandement les performances (move semantic, perfect forwarding, static dispatch, compile time evaluation)). 5 ans après, j’étais devenu le référent technique C++, tous n’a pas été pris de ce que je faisais bien évidemment, et moi-même j’ai évolué sur ma pratique, je l’ai peaufinée, mais aujourd’hui plus personne ne code à l’ancienne (à la C) dans la boîte, le manager, qui a un bon bagage technique m’a missionné de former tous les devs aux techniques que j’avais introduites qui étaient communément encensées et le nombre de bugs liés à des problèmes mémoires (double free, perte de mémoire ou même seg fault) s’est réduit drastiquement et la plupart du temps, quand on en découvre, c’est sur du code legacy justement.
Continuant de faire ma veille technologique, j’ai aussi été un lobbyiste pour adopter le rust pour remplacer le C++ (pour pleins de raisons diverses, les principales étant la facilité d’apprentissage pour les nouveaux devs et les sécurités de code que ce langage introduit vis-à-vis du C++), maintenant que je suis parti de la boîte, j’apprends qu’ils envisagent de s’y mettre.
Donc ici, vis à vis de ce que tu dis, ce que j’ai introduit était en parti dans le but d’améliorer la lisibilité du code, et pour le rust, il s’agissait d’adopter un langage qui soit bien plus simple à apprendre que le C++ (qui est, je pense, un des langages les plus difficiles à maîtriser, plein de langages ont été créé précisément dans le but de faire un C++ plus simple comme le C#, le D, le go), mais dans l’absolu, tout ceci est complètement nouveau pour les anciens devs, qui à l’époque avaient donc du mal avec ce que je faisais, c’était trop différent de leur pratique, et apprendre un tout nouveau langage, qui certes s’inspire fortement du C++, mais qui est quand même très différent sur pleins de points, c’est même un stade au dessus de ce que tu dis être des mauvaises pratiques. Et pourtant, ce que j’ai fais a réellement apporté un plus à l’équipe, une fois formée.
Donc être ouvert aux nouveautés c’est quand même important, mais surtout il faut savoir justifier pourquoi et évidemment, j’ai conscience que dans d’autres entreprises, ça ne se serait pas forcément passé ainsi.
Gg d'avoir réussi à transmettre ce savoir et l'avoir fait adopter. Ce n'est pas facile de faire changer les habitudes
Je ne trouve pas le C# si simple que cela. J'ai été obligé de rétrograder du code pour des collègues et je peux te dire que j'étais le seul avec un consultant externe que l'on déplaçait depuis 20 ans qui savait de mémoire faire les différences entre les versions de C#. J'ai remarqué deux tendances dans le domaine premièrement, il y a les métiers de la gestions administrateur réseau, DBA, autres. Puis, il y a les faux informaticiens comme ceux qui prétend que de connaître SAP HANA demande 4 ans d'expérience et qu'ils méritent plus cher ou les autres qui sont des statisticiens, mais utilise un logiciel de calcul quand même pour convaincre les autres qu'il ne faut pas faire d'étude pour devenir pro des mathématiques. Les développeurs sont des bouches-trous, tu es là pour écrire du code et selon le niveau de complexité que tu veux imposer pour faire évoluer ton système, tu risques plus ou moins de perdre ton emploi parce que tout ce que l'on veut de toi, c'est des trucs à présenter au conseil d'administration pour montrer que l'on fait quelque chose et qu'ils ne savant pas lire une documentation technique. Je ne suis pas capable de coder à mon niveau dans une entreprise, ils ne respectent pas suffisamment les diplômes et ce n'est pas une question de talent, j'aimerais bien que la personne consulte le PMBOK, le SWEBOK et maîtrise quelques méthodes formelles. Je ne veux pas rigoler, mais on ne m'a pas passé en entrevue pour une expérience sur un projet open source dont j'ai contribué. Ils avaient une liste d'entreprises valables dans leur cas, mais je ne peux pas avoir l'expérience de mon propre code dans cette industrie et je dois les respecter. Je travaille mais ne me demande pas d'implication si je veux une bonne situation financière, c'est par mes propres moyens et non comme employé.
@@BelleMorue je ne dis pas qu'ils ont réussi à faire un langage plus simple que c++, je dis que c'était leur but à la base. Je ne connais pas C# je serai bien incapable de te dire si c'est le cas où non. Cela dit, C++ a l'air universellement reconnu comme un langage trop complexe.
Après, les nouveautés, quand on fait du C++... c'est pas exactement des nouveautés ! Particulièrement à l'époque dont tu parle. Le standard prend son temps pour évoluer. Rien à voir avec les ruées qu'on pouvait constater à la même époque dans le monde de JavaScript. D'ailleurs, quand C++11 est devenu le nouveau standard, ça faisait 8 ans qu'il n'y avait pas eu de mises à jours majeures.
En ce qui concerne Rust, à titre personnel, justement, j'attend encore quelques années avant de _peut-être_ m'y mettre. Il y a encore trop de controverse sur le sujet, et je préfère attendre 1) que la poussière tombe, 2) que le langage prenne en maturité (ce dernier point ne pouvant se faire qu'avec suffisament d'utilisateurs et de temps investi).
Donc pour le moment, je continuerai de développer mes applications et mes sites webs en C++ !
@@Harold046 Les nouveautés en C++ ne sont pas exactement des nouveautés ? Alors, comme je le sous-entendais, les devs de ma boîte codaient "à la C", donc n’utilisaient pas les fonctionnalités de C++11, donc pas de lambda, pas de move semantic, pas de templates variadique, pas de range-based loop, pas de constexpr, pas d’auto, pas d’header type_traits (et donc pas de SFINAE), pas de mutex standard (et donc pas de lock_guard), pas de thread standard, pas d’assertion statique, pas d’enum class, pas de smart pointer utile (auto_ptr était une catastrophe), pas de regex standard… Toutes ces fonctionnalités changent fondamentalement la façon de coder en C++ ce qui rend du code C++11 drastiquement différent d’un code C++03.
Le C++11 a mis longtemps à venir parce que beaucoup de choses était prévu à la base, les concepts notamment étaient déjà prévu en C++11 mais on été retirés, les concepts changent aussi beaucoup de choses en méta-programmation en C++. De manière générale, C++20 est une mise à jour au moins aussi importante que C++11 l’a été en son temps avec l’introduction des concepts, les contraintes, les coroutines et des modules.
fichtrement raison. Je te remercie, Simon! Tes mots sont comme des paroles gravées dans une pierre.
Merci vraiment bien pour tes video!!! Je te suie depuis le Burkina Faso !! Et ca m'aide en tant que Dev Junior
Merci pour ton message, c'est le principal objectif des vidéos : pouvoir vous aider même d'un millimètre dans la vraie vie. 👍
Ce n'est peut-être pas grand chose mais je tiens a te remercier pour la qualité de tes conseils ainsi que des recommandations littéraire surtout en ce qui concerne la productivité ! Bon courage a toi en ce qui concerne le coaching de vos futurs recrue ainsi que tes futurs projets
Salut, merci pour ton message de remerciements. Tu as bien fait de prendre le temps de l'écrire, c'est toujours apprécié. :)
Bon code !
Simon.
Si ton senior n'était pas content de tes imports en cascade, il aurait dû installer un linter comme Prettier qui t'aurait évité ça. C'est son boulot d'encadrer les juniors et même les seniors avec les bons outils de contrôle de code.
Si un de mes juniors committe du code comme ça je considère que c'est pas de leur faute mais de la mienne
Hello, je salue votre approche, elle peut sauver des équipes et des projets. 💪
👉 Tous les aspirants Tech Lead doivent lire ça :
"Si un de mes juniors committe du code comme ça je considère que c'est pas de leur faute mais de la mienne"
Cette remarque est dépendante du contexte. Il faut un minimum que les développeurs soient responsabilisés et tout n'incombe pas au tech. lead. J'ai vu de réelles mentalités à deconstruire avec des devs qui ne relisaient même pas leur code avant d'envoyer en review.
Les outils comme prettier/eslint sont d'une aide très précieuse mais certains concepts sont juste trop difficiles à contrôler via ces outils, il y a une limite. Selon le niveau de connaissance/ bande passante du tech. lead, certaines choses passent à la trappe, personne n'est infaillible.
Voilà, je voulais juste tempérer un peu les propos car la réalité est très souvent nuancée.
@@monome9992 Tout ne repose pas sur les épaules du Tech Lead, mais j'aime bien faire comme si. Cela me permet de garder le contrôle sur ce qu'il se passe. Quelqu'un livre n'importe quoi ? Pourquoi ne pas organiser un workshop pour progresser sur ce point ? C'est le genre de croyance fausse que je trouve utile.
Haha je me suis dis pareil direct. En tant que Tech Lead j'ai mis des jobs de CI/CD bien strict et tant que ça ne passe pas, le développeur dois retravailler son code (lint, type checking, tests unitaires, build,...)
Par rapport a la relation au marketing qui change tout le temp d'avis, tant qu'on te demande pas de modifié le code en cours de sprint ca me va. Le PO est le coordinateur et c'est son rôle de refuser. Dans les plus petites entreprises, il n'y a pas toujours de PO qui calme les ardeurs du marketing.
merci pour ces précisions, vos interventions sur les questions de programmation sont au sommet de l'excellence.
Merci pour ce commentaire élogieux. Mon minuscule ego est flatté.
Salut Simon. Merci pour tes précieux conseils. Que penses-tu de l'idée de créer un slack d'entraide pour les personnes qui regardent tes vidéos ?
Merci Simon... Je me lance dans l'amelioration.
Merci beaucoup Simon c'est vraiment interessant tes partages d'expériences. La productivité est capitale sinon on laisse place à la baisse de performance.
la qualité est importante également.. produire mieux quitte à produire moins
Bonsoir Professeur, vraiment merci infiniment pour ce beau tuto. Je suis très heureux de vous retrouver. Merci encore une foie de plus pour votre partage du savoir.
Thx pour tes vidéos, ça permet des bonnes petites remises en question qui font du bien 😊
Héhé, de temps en temps il faut !
Attention tout de même aux revirement du marketing : car si tu as tout fait pour rester KISS et YAGNI ( pour sortir ton MVP au plus vite) alors ton code ne sera pas forcément robuste aux changements 😅
C'est très perturbant de voir que les habitudes décrites ici correspondent à ce qui est la norme dans mon entreprise au niveau du comportement des seniors (excepté pour la robe rouge)...
Merci pour cette publication, que j'ai trouvé très pertinente, comme souvent dans ton contenu. Merci également de nous partager tes expériences et références. Bravo!
Merci pour ton retour positif !
Bon code à toi et à bientôt,
Simon.
pour les horaires de dev, 6h -> midi solaire. (voir rythme circadien)
en mode indisponible et dans le silence.
jamais fatigué.
très bons conseils...
Hello, intéressant. J’ai deux questions :
- vous travaillez en deep work de 6h à midi c’est bien ça ?
- est ce que vous avez besoin de vous synchroniser avec d’autres personnes ? Si oui, quand le faites vous ?
@@codeursenior
de 6 h vers 13-14 heure
ensuite je peux faire les tâches administratives et la communication l'après midi.
je privilégie les communications asynchrones et j'ai banni le mot ''urgence''.
c'est vrai qu'en ce moment je travaille seul.
en début d'année, je vais commencer à déposer mes travaux Open Source.
je vais donc possiblement rentrer en contact avec des personnes du monde entier. de ce fait, il n'y a pas trop d'horaires à respecter.
comme le dit la philosophie Zen, ne faire qu'une seule chose à la fois et le faire pleinement.
sortir du brouhaha de l'hyper-communication et faire la tâche que l'on s'est donné.
pour finir, sortir de l'hyper-utilisation de technologies peu stables.
Au top comme toujours ! Merci pour ces conseils ✌
Merci pour ta vidéo, je souhaiterai devenir développeur, comment le devenir ? Ou se former ? Quelles écoles et centre de formation ? Les qualifications suite aux formations sont-elles reconnues par les entreprises ... ? Ce serait un thème de vidéo qui m'intéresserai.
Hello, merci pour tes questions. Je n'aborde généralement pas ces sujets qui sont très "tôt" dans le parcours d'un développeur. J'ai tout de même ajouté tes questions à ma liste d'idée de prochaines vidéos possibles.
Bon apprentissage !
P.S : Pas besoin de diplôme pour commencer à coder, Internet est ton école pour le moment.
Pour ma part, je commence ma reconversion au centre de formation Arinfo. C'est une formation adulte, niveau bac+2 en sortie, certification reconnue par l'état. Si cela peut vous aider...
@@nathalietellier4165 Merci pour le partage d'expérience. Bon apprentissage et bon code à vous, ne lâchez rien. 💪
Bonjour, je viens témoigner moi aussi, j'ai pour ma part commencé une formation de développeur web et Web Mobile pour le compte de Créative Formation, ils proposent cette formation un peu partout dans les villes moyennes(Caen, Le Mans, ect); pour ce qui est de commencer, les cours gratuits d'OpenClassRooms m'ont fournis une bosse base; Je vous conseille fortement de commencer dans votre coin et de ne pas attendre de vous retrouver en formation, ce sont des formation à courte durée où l'on à pas forcément le temps de bien s'attarder sur des notions-clés du développement.
Commencez chez vous, à votre rythme, rentabilisez le temps que vous avez aujourd'hui pour être plus à votre aise une fois en formation (c'est comme sa que j'ai fait et je suis plutôt à l'aise pour le moment (enfin si j'arrête un jour de m'imposer l'apprentissage des diverses techno en plus de mon programme de formation xd))
Franchement Super, un Gros Merci !
Merci Simon pour cette vidéo très instructive. Je viens de finir une formation de dev web et je suis en recherche d’emploi. Tes conseils vont m’être utile.
Au top, merci pour votre partage d'expérience. J'espère pouvoir vous aider à travers cette chaîne.
Merci pour ton travail
Merci à toi et bon code !
Mercii pour cet enrichissement que tu partage 🤍
Merci pour votre retour positif, bon code !
Simon.
Excellent, merci.
Merci pour la vidéo et tout ton travail sur ta chaîne 😁
Au top, merci pour ton message, ça fait bien plaisir.
Bon code à toi,
Simon.
Salut mec j'espère que tu es au top ,bref j'ai beaucoup question te poser notamment node JS et premièrement j'ai envi de m'assurer que tu me repends dabors 😂
Je suis ingénieur mais pas développeur, loin de la, mais tout les conseils de cette vidéos sont largement transposables à d'autres positions de création/ingénierie. Superbe vidéo
Merci pour ton partage Simon...
Merci à toi pour ton retour, bon code. Simon.
Merci Simon
4:06 je me souviens du code shell cryptique que je voyais sur des blogs il y a une dizaine d'années. Je me sentais nul parce que je ne comprenais pas rapidement ce que faisait ce code. Maintenant, je me dis que je n'aurais pas aimé travailler avec ceux qui écrivaient ces commandes.
Dans le même genre, il y a les solutions les mieux notées des puzzles codingame où le code est le plus concis possible. C'est dommage que la plateforme mette en avant ces solutions très éloignées du code professionnel.
"Tu aurais dû choisir le backend "👍🏾
La dernière des habitudes m'a tellement parlé. C'est normal alors docteur ? 😂
Très chouette vidéo
Le point sur marketing c'est peut-être aussi un problème de formation, comme le point 1 d'ailleurs...
Ne pas comprendre comment fonctionne une entreprise et qu'elle s'insère dans un environnement concurrentiel, c'est un vrai problème qui dépasse le soft skill à mon avis.
On embauche pas des devs pour le plaisir mais répondre à des besoins. Et ça se découvre avec le temps, le marché évolue aussi...
très intéressant. la femme à la robe rouge, c'est toute ma vie... pire que ça, pour moi, c'est comme si elle en avait pas.
please une video sur le Big O notation!
Oulà, je n'ai rien à dire d'intéressant sur le sujet. Vous trouverez sûrement quelqu'un de plus compétent sur le sujet. Bon code et à bientôt, Simon.
En tant que freelance, n'est-ce pas une perte de temps et surtout d'argent d'accepter que le marketing change d'avis ? Si la demande est accompagnée d'une compensation financière, je n'ai rien à dire, mais s'il faut assumer sois même, je ne suis pas d'accord avec l'argument du challenge. Je reste cependant enclin à être flexible pour d'éventuels ajustements, mais ça doit rester raisonnable à mon avis.
En tant que freelance, tu chiffres ton activité. Si tu ne le fais pas ou si tu ne sais pas le faire, tu es un mauvais freelance. Le jeu c est de vendre sa compétence en jour travaillé et marger sur cette valeur. Le changement fait partie de la facture.
@@fredericlossignol3874 En tant que freelance, tu fournis surtout un travail et du temps que tu ne veux pas gâcher. La règle est simple : vie = temps = argent. Donc oui mon temps est précieux et je le donne pas à volonté.
Merci beaucoup à toi
signe n°1: le développeur inexpérimenté se fait clickbait par cette vidéo.
le développeur senior lui reconnait le gros putacliquage et dodge
C'est sûr que le développeur senior n'a pas grand-chose à faire sur une chaîne qui aide à devenir développeur senior. Puisqu'il est déjà développeur senior. C'est pas une question de putacliquage, c'est seulement logique.
Pour le développeur junior, je trouve que les conseils sont pertinents.
5:44 Très belle référence Sim-One ! 😊
Pillule bleue ou pillule rouge ?
Ahhhhh, pilule rouge, bien évidemment. 😄 Tellement mythique cette scène.
Au passage, je ne sais pas si c'est toi qui fait le montage, mais tes cuts sont propres. On a presque l'impression que tu as fait ton enregistrement d'une traite. 👌🏽
@@dominiquetalis1516 Bien joué team #PiluleRouge ! Ecoute merci, c'est la première fois que quelqu'un me dit que le montage est propre. 😂
Pour le moment je fait encore le montage à la main, j'envisage de sous-traiter cela en 2024. Bon code à toi !
@@codeursenior Merci, bon code à toi aussi.
Merci beaucoup pour cette vidéo tu es un 10.
Hello, 10/20 ? Pas mal c’est la moyenne, ce qui correspond à mon niveau durant toute ma scolarité. 👍
"Bah, ça prendra cinq minutes'--> Développeur junior😝
E.X.C.E.L.L.E.N.T ! 😂😂😂
Je me demande comment j'ai pu l'oublier celle-là. Merci !
éviter de vouloir bien faire les choses, quand on est inexpérimenté on ne sait pas encore que ce qui n'est pas fait à la première livraison sera refacturé le double en corrections ultérieures 😅
merci !
Quand vous remarquez un youtuber vous conseille avec des références experience + livres lues, Abonner toute suite. c'est un bon
Ah le légendaire x2 sur les tutos m'a pire manie ça, j'ai regarder ta vidéo en normal là par contre, faut bien faire une petite pause entre deux scripts.
J'aime bien les commentaires avec de la forme, bien sûr, cela ne devrait pas prendre plus de 2 secondes à être fait.
Là est une grosse partie du problème, je devenais développeur de commenaire !
Salut merci pour la vidéo, Quesiton :
Reussir le test du refactoring présenté dans la vidéo comme un changement d'avis du marketing et respecté le principe YAGNI n'es pas contradictoire ?
Comment faire du code capable de s'adapter quand on s'interdit de partir sur un design pattern aprés 3 else if ?
Merci (question ouverte à tous).
Mon avis :
C'est une aussi une question de bon sens et d'expérience.
Imaginons tu as un système COEUR + modules A/B/C (module = fonctionnalité genre envoi de SMS ou autre)
Si ton "else / if" permet de charger tes modules en dur dans le code, ok tu as 3 modules donc un système IF/ELSE suffit (ie
Salut. J'apprends Python. Pour passer de débutant à confirmé, je tourne en boucle. 😮
Hello, est-ce que vous travaillez en entreprise ou freelance ?
Je n'ai pas progressé en code pendant toutes mes études car nous étions coincé dans "tutorial land".
@@codeursenior J'apprends seul sur Udemy avant de commencer l'université.
@@serge_amon C'est très bien Udemy. Vous pourriez vous trouver un projet personnel avec quelques utilisateurs ou travailler avec d'autres développeurs en apprentissage pour vous forcer à vous confronter à plus de feedback. Bon apprentissage et bon code à vous !
Top merci
Au plaisir, bon code !
Ben ouhe Simon il faut savoir « se vendre » et avoir la tchache mais je ne suis pas plus avancée pour autant et qu’au début de ma reconversion et je ne sais pas si j’y vais ou je passe à autre chose et pourtant je suis motivée.
Hello, je préparer une "grosse vidéo" de 90 minutes qui ne sera pas sur UA-cam (le format ne s'y prête pas) ou j'essayerai de vous donner une sorte de roadmap qui a marché pour mes élèves et moi-même dans leur reconversion. A bientôt j'espère, ne vous découragez pas... codez !
thanks🙏🙏🙏🙏
Bonjour, j'aimerai m'inscrire sur ton news-letter
Je vais testé la règle des 100, je suis ultra débutant en alternance, mais je me distrais vite
Hello, excellente décision et ne lâchez rien… la fille à la robe rouge ne vas faire que passer pour vous distraite.
Merci bien @@codeursenior
@@CodeZeroToHero 🚀
cela serait possible de rentrer plus dans le détail plus palpable? , cela fais 2 ans que je suis développeur en entreprise je n'ai jamais rencontré les problèmes exprimé ici même les première semaines. Est il possible d'axer sur des choses concrète qui nous permettrait de mieux nous définir dans notre travail. exemple: quel approche va prendre un senior pour la sécurisation de plusieurs key , comment un senior exploite le MultiThreading pour optimiser le plus possible l'efficience du logiciel. Quel sont les pratiques qu'il mettra systématiquement en place pour minimiser les appel externes et recycler le plus possible les données pour éviter de nouveau appel. Je me considère junior car pour moi ces questions ouvre plusieurs choix la ou un senior devrais ne voir qu'une seul réponse toujours valable est applicable ( il y a plusieurs chemin pour arriver à destination mais un seul sera le plus court)
Je me permets une remarque : en développement, et encore plus en ingénierie informatique, il y a rarement une solution claire et évidente, parce que la solution "optimale" dépends de nombreux facteurs contextuels: expérience et compétences de l'équipe, état de la base de code, langage et technologies utilisées, contraintes de fiabilité, de performances, d'évolutivité, ...
En fait, c'est de la résolution de problème complexe, et pour ça ya globalement une seule méthode : essai et erreur jusqu'à que ca marche. Une différence entre un junior et un sénior dans ce cas, c'est que en général le sénior est plus cultivé, a déjà été confronté à de nombreux problèmes, et souvent des problèmes similaires, et donc il a une meilleur idée de là où il faut chercher en premier, et aussi une plus grande capacité d'analyse.
Par exemple dans le cas du multithreading pour optimiser l'efficience du logiciel, un sénior répondrait probablement : aucune idée sans plus d'info. D'autant que ça dépends comment on compte l'efficience, mais en général un logiciel multithread est moins efficient qu'un logiciel monothread, parce qu'il y a un coût supplémentaire en temps et en mémoire pour orchestrer les threads.
@@felixbertoni merci beaucoup pour votre commentaire au contraire il faut que plus de gens comme vous se permettent de répondre , ça me donne déjà beaucoup d’éclaircie notamment sur l’approche, ça corrobore ma façon de faire et me rassure un peu de pas être dans la mauvaise voie. Désolé pour le manque de contexte l’idée été de pose de grand point d’interrogation global. Effectivement j’ai une méthode empirique pour avancer dans une problématique. Cela me semblait être une mauvaise approche du fait de la perte de temps que cela génère mais vous me rassurez déjà beaucoup.
En ce qui concerne la résolution de problème je vois exactement ce que vous voulez dire ahah par fois on voit un soucis qui sort de nul part et on sait le résoudre presque naturellement sans avoir besoin de chercher c’est déroutant. Au plaisir d’échanger merci encore pour la réponse
Merci
Merci pour ton retour, bon code !
Merci senpai !
Excellent ce terme de "senpai", merci pour la découverte !
Bonjour leader, quel dev angular étiez-vous?
Bonjour, je suis passé par les 5 signes présentés dans la vidéo ! 👍
😂 je commente grave mon code
Par contre quand je suis sur un bug impossible de faire autre chose tant que c’est pas résolu.
Pour les commentaires, j’aurais tendance à attaquer la « diète » la dessus. De mon expérience cela crée assez peu de valeur. Par contre être tenace sur les defect, bien joué, même si parfois une pause est salvatrice. Bon code !
Ce que je remarque le plus avec les développeurs moins expérimentés, c'est un manque de respect de l'architecture. Lorsqu'ils codent , on dirait qu' ils n'arrivent pas s'imprégner du style de programmation de l'ensemble du code. Je n'ai pas d'appréciation, je dois être difficile à aider parce que c'est rare que l'on vient m'expliquer la technique, on me donne un design et je dois commencer à valider à la conception. Si la conception ne fonctionne pas, j'ai des maux de ventre parce que faire bouger un architecte, il faut plus que des mots. Tu dois le montrer avec un contre exemple où cela ne fonctionne pas. Il faut avoir une solution avant d'exposer un problème. Ce n'est pas un client, tu as gorille de l'informatique devant toi et il va poser des questions exigeantes qui demandent de penser plus rapidement que tu le fais normalement et bien le faire. Biensure, ils vont trouver un truc génial bien meilleur que ta solution, mais ils vont savoir que tu comprends bien leur idées.
Bonne analyse !
Astuce: "chez ATOS" c'est plus simple pour la diction (et plus accadémique)
Bon sang, vous avez raison. Vous n'êtes pas le premier à me le dire, j'espère que vous serez le dernier !
Bon code,
Simon.
Si tu consultes un Grevisse (par exemple) tu verras que "chez", selon les puristes, ne doit s'employer qu'avant un nom de personne. On dit donc chez Leroy-Merlin, chez Darty, mais À Atos.
@@puneeification Énorme ! Merci pour ce revirement de situation. Je ne change rien du coup. 😅😅
c est TOP
J'ai maintenant 66 ans et cela me fait drôle de voir un jeune qui reprend mes paroles😂
Quand tu t'aventures en freelance tu découvres que la première difficulté c'est de former les junior sans les pousser à la démission.
Il faut pas former trop fort !
@@codeursenior Pour l'instant je sais pas faire. Je leur montre la source d'un jeu de pong, quand ils découvrent le niveau à atteindre ils renoncent à tout jamais à devenir programmeurs.
@@LivingDeadApocalypse Ah là, c'est mal parti. Après tout le monde n'est pas fait pour ce métier, qui est assez particulier finalement.
@@codeursenior wé je fais le tri je suis un genre de psycho-test avant d'entrer à la fac. je devrais en faire un tutoriel en vidéo
Franchement vu l'historique d'Atos est comment il traite leur consultant c'est pas très glorieux d'en parler c'est tout sauf une référence Atos.
De plus pas étonnant que tu es été choisis en tant que jeune formateur le principe de cette compagnie étant de faire un max d'argent sur les TJM concernant les juniors.
Je parlerais même pas d'être le premier Junior de France en tant que formateur Java ça reste à prouver et je ne vois pas l'intérêt de mettre ça en avant.
Reste toi même tu es encore jeune !
"Je parlerais même pas d'être le premier Junior de France en tant que formateur Java ça reste à prouver"
La phrase exacte "un des plus jeune formateur JavaScript de France". Je peux le prouver avec mon ordre de mission de l'époque quand j'avais 26 ans.
Du coup :
Java => JavaScript
Premier => Plus jeune
Je suis un débutant sur l'informatique et j'étudie à l'université de Douala au Cameroun, quel conseil dois-je ou pouvez vous me donner pour être un développeur professionnel c'est AHAMAT CHAIBO
Si j'ai un conseil à te donner, c'est de d'abord te poser une question essentielle : je veux devenir développeur pour quoi ? Quand tu aura répondu à cette question, tu pourras choisir un langage, même s'il est en dehors de ce que tu apprends à l'université, qui correspond à tes attentes. Ensuite, le plus important sera de rester focus sur ce langage afin de, dans un premier temps, comprendre les fondamentaux (variables, types, boucles, structure de données, algorithmie, ...) de la programmation, et ensuite, maîtriser la syntaxe du langage. Dernier conseil, tu vas souvent te confronter à des problèmes qui te semble insolvables. Ne baisse pas les bras, à ce moment-là. C'est dans la difficulté, qu'on apprend réellement à programmer. Bon courage à toi. 👋🏽
Mon conseil serait de commencer par les bases : le C par exemple (ou mieux l'asm 🥳), avant de se tourner vers les languages plus haut niveaux (oop, script, bytecode, etc.)
2eme conseil s'intéresser au monde libre, open source, voire y contribuer. Cela permet de voir du beau code et d'apprendre les bases dans un environnement "pédagogique" (c'était le cas des vieilles distros linux qui mtn ont tendance à un peu trop se windowiser) le tout pour gratuit.
Voila pourquoi faire une ecole d’ingénieur cest tres avantageux parce quon ty apprends la plus part de ce que tu dis dans cette video… excellents conseils
Si seulement ;) Pour fréquenter beaucoup d'ingés à différents niveaux d'expérience, les points cruciaux énoncés dans la vidéo sont rarement compris de façon intuitive, et créent parfois carrément un rejet. C'est d'ailleurs particulièrement commun avec les français dont le sens commercial est de base très mauvais par rapport à celui de l'américain ou du canadien moyen, sans parler du complexe de supériorité école d'ingé assez dévastateur.
Chatgpt avec dallee est beaucoup utilisé ahahah c'est trop bien
Ag oui carrément, je ne peux plus m'en passer ! 🤩
Dans le même style que Jimmy Neutron, t'as l'effet Dunnning Kruger qui consiste à sur estimer ses capacités. Puis, avec l'expérience tu te rends compte qu'il te reste beaucoup à apprendre
mdr l'intro tu m'as tué
Avec plaisir, c'est de bons souvenirs...
5/10 ya des choses interessantes dans la vidéo, un retour d'expérience assez bon dans l'ensemble mais je trouve votre communication assez mauvaise car vous faites trop de jugement précoce
dans les jeux vidéo les filles en robe rouge sont une catastrophe socio-économique
neo: hé regarde les derniers unity unreal godot
morpheus: ON CODE POUR SMARTPHONE BORDEL
Commentaire de légende.
il était où avant ?
Ne pas faire de veille technologique est quand même un très mauvais conseil. Bien sur que si il faut regarde les nouveautés. C'est même la base.
Oui enfin c'est juste pour impressionner les recruteurs ou bosser genre a Google. Arrivé en Mission ça utilise des solutions gratuites ou qui date car budget serré 😅
👍👍
🚀
c'est dingue des mots english dans chaque phrase
c'est pas possible de parler vraiment french ?
parce que parler franglais à tout bout de champ, ça devient vite boring
Les informaticiens ont certainement l'anglais un peu facile. la plupart des docs ou des ouvrages intéresants sont en anglais de nos jours.. pas souvent traduits
Je n'aime pas le titre de la video.
Ingénieur n’est pas développeur, les vrais ingénieurs sont souvent du côté soft skills et manager …
Ca dépend du domaine. Dans des boites ou la R&D est primordiale, genre OpenAI ou en FinTech, les ingénieurs, qui ont souvent un doctorat, utilisent beaucoup leurs hard skills.
Tout à fait, je ne vois pas comment on peut se prétendre ingénieur sans hard skills.
🥰🥰🥰
Atos les opticiens 😅
Atos, Portos et Aramis. 😅
Désolé mais apprendre à faire une présentation, ce n'est pas un softskill. C'est un hardskill qui n'est pas purement IT, mais pas un softskill. Les softskills sont tout ce qui a trait à ta personnalité globalement.
Le retour de bâton on dit. C’est bien tu as réussi à faire ton bilan. L’important est de voir ses erreurs et les corriger
Hello, tout à fait. Prendre là où on en est, et itérer pour essayer d'avancer. Bon code !
Les autres ne font rien ... Tu étais sacrement con à 24 ans quand même xD
Jesus peut transformer ta vie 🔥
Merci ! Je me sens prêt, que dois-je faire ?
❤️👃❤️🌻❤️
👍 ref
💊 ou 💊 ?
gg
Mdrr cet émoji est incroyable, bien joué. 👍
merci
De rien, bon code à vous. Simon.