Juste parfait, en 1 an t'as parfaitement compris les directions où il faut creuser pour avancer en code & produire des choses. Chapeau bas. Et ça fait plaisir de trouver ça sur une chaîne où ça a des chances d'inspirer des gens qui vont commencer à apprendre à coder, tu pointes les bons chemins ! 😁
Pas mal comme vidéo, tu as capté une bonne partie des éléments que doivent connaitre les développeurs expérimentés. Je mettrais tout de même plus de nuances sur tes 2 derniers points : - La productivité est quelque chose qui est extrêmement compliqué à quantifier dans le domaine de la programmation. Est-ce que c'est le nombre de lignes de code pondues par jour ? La capacité de résoudre un problème ? De fournir le code le plus modulaire ?De répondre aux attentes du client de la manière la plus efficace ? Probablement un peu de tout ça, mais chacune de ces qualités ne sont généralement pas partagées par les mêmes personnes (en tout cas sur un projet d'envergure). C'est pour ça que les métiers de architectes, analystes développeurs, testeurs,... existent. Dans les faits, en tant que professionnel, tu seras amené à toucher à tout ça mais il y a une vrai expertise dans chacun de ces métiers qui demandent des années d'expérience (et encore ici, je ne fais qu'effleurer la surface). Pour les lignes de code, c'est encore plus compliqué à jauger, tant cela peut varier selon le problème traité et leur complexité. Certains protocoles, comme l'échange de clé de Diffie-Hellman sont très simple à implémenter (quelques centaines de lignes tout au plus) mais ont encore un énorme impact sur la cryptographie "Pre-quantum". Néanmoins, il a fallu beaucoup de travail en amont en informatique théorique pour déterminer que cette méthode était sécurisée pour échanger des clés. Pour rester dans le domaine de la cryptographie, il est bon de rappeler que non, les gens qui ont le plus d'impact ne sont pas "les superstars des GAFAM" mais sont souvent avant tout des chercheurs universitaires passionnés. Je finirais ce point en reprenant cette phrase qu'on attribue à Ken Thompson (le créateur des systèmes UNIX) "One of my most productive days was throwing away 1,000 lines of code". - Sur ton dernier point, c'est une grave erreur, à mon sens, de réduire un projet à une simple question de coût. En project management, on parle plutôt du triangle Cost-Time-Scope (+ la qualité qui peut-être plus ou moins arbitraire). Je te laisse te renseigner sur ce point car la gestion de projet, c'est pas ma passion. Je vais juste ajouter un point sur la sécurité (mon domaine) : toutes les personnes de l'industrie te diront que c'est irresponsable de ne pas inclure (du tout) la sécurité dans ton processus et que celle-ci a un prix certain. Le problème, c'est que la sécurité n'a pas d'intérêt objectif pour une entreprise (pas de ROI) et ce n'est que lorsque le mal est fait qu'on peut voir l'ampleur des dégâts. La sécurité informatique devrait être considéré comme quelque chose dont l'intérêt est supérieur à son coût (comme le secteur public de la santé par exemple). Il est donc nécessaire à mon sens de sortir de ce paradigme du "Limiter les coûts à tout prix".
Sur la partie des coûts , je suis absolument d’accord C’est d’ailleurs l’une des bases des cabinets d’investissements , il achète toutes les boîtes d’un secteur de niche qui a un potentiel énorme car ils savent que l’une d’entre elles va forcément exploser
Je n'ai pas lu de commentaire aussi intéressant depuis très longtemps. Est-ce que tu aurais quelques bonnes ressources pour ce familiariser avec la gestion de projet (livres, vidéos, sites...) ?
@@frerejacques9652 en termes de livres, tu as les 2 Bibles du domaine : le Project Management Body Of Knowledge du Project Management Institute et Prince2 que tu devrais pouvoir chopper gratuitement, mais bon ça reste 2 grosses briques pas forcément digestes si tu veux feuilleter par simple curiosité. Je te recommande à la place la page wikipedia de la gestion de projet. Si tu es à l'aise avec l'anglais, je te conseille sa version originale "Project management", que je trouve bien plus illustrée et détaillée (avec de nombreuses références vers d'autres articles) que la version française. En termes de vidéos, je ne pourrai pas te répondre, je n'en connais pas. Je te conseillerais tout de même d'être prudent (surtout avec le format vidéo) car la gestion de projet est gangrenée par le storytelling et le marketing notamment quand tu vas entendre parler des méthodes agiles, scrum, XP, ... Sur ce dernier point, encore une fois, la page wikipedia prend bien plus de recul et s'attarde (au moins un minimum) sur les différentes critiques qui ont été amenées à ces méthodes
Salut, j'ai une douzaine d'années d'expérience dans le dev, j'ai vu beaucoup de profils différents de développeurs, lead et architectes durant toutes ces années, et je me permets de te dire que je trouve que tu balances un énorme poncif d'entrée. On retrouve pléthore d'excellent lead dev ou dev senior, excellents orateurs et pédagogues. Le cliché des geeks introvertis qui sont meilleurs que ceux plus à l'aise socialement, il est faux et révolu depuis les années 2010. La vérité c'est qu'il n'y a pas de règle de ce côté là, on trouve de tout et aucun profil psychologique n'a le monopole du génie dans le dev. C'est bien de se méfier de ceux qui parlent "trop" mais attention avec tes "jamais". Tu as eu une excellente approche de repartir de zéro à chaque fois pour faire mieux, c'est vraiment en ce moment dans ta carrière que tu as le temps de faire les choses bien pour prendre les bons réflexes et les bonnes habitudes. Le métier de dev, c'est 99% non pas de débrouille mais de réflexes, et ce sont ces réflexes et bonnes pratiques acquis qui font que l'on va de plus en plus vite à faire de la qualité. Il faut tout miser sur comment acquérir ces réflexes et ça passe par la répétition et la confrontation avec de nouvelles choses à implémenter en permanence. J'aime beaucoup comment tu présentes le TDD et pourquoi ça vous aurait aidé à aller plus vite, ce cas complexe qui aurait été traité en itérant je le trouve idéal pour l'introduire.
merci, ça m'a choquée qu'il raconte ça dès le départ. Je travaille dans ce milieux (même si je ne suis pas dev) et je constate bien également qu'il y a des développeurs timides et des lead Dev, et le lead dev sait à la fois coder, former aux bonnes pratiques de dev et s'exprimer sans problème. Bref, la règle en matière de crédibilité, c'est d'éviter les raisonnements à l'emporte-pièce, et donc les 'jamais' ainsi que les 'quasiment jamais' qui ne sont que des variantes rhétoriques ;)
Si je peux me permettre la suite, J'ai 37 ans et je suis un débutant bêta dans la programmation, notamment sur l'IA. Votre propos reflète votre niveau parce que vous oubliez qu'il s'adresse aux novices. Lorsqu'il fait une telle introduction, c'est pour clairement aider les novices à se situer dans le domaine, c'est-à-dire est-ce qu'il veut devenir un codeur pro à temps plein ou avoir juste les rudiments pour faire du marketing ou diriger une équipe. Bref, il est question là de comprendre qu'on ne peut être dans le back office et le front office au même moment, confère tous les entrepreneurs célèbres de la high-tech, qui ont commencé dans le back office pour finir dans le front office. Ensuite, lorsqu'il parle de "débrouille" c'est encore adressé aux novices. Effectivement, avec le temps, ces "débrouilles" vont se tranformer en "réflexes". Pour être franc, sa vidéo m'a beaucoup éclairci la vision de l'apprentissage de la programmation car elle répond à beaucoup de blocus surtout que je le fais en autodidacte. Sauf que mon âge est le dernier blocus, vais-je y arriver à mon âge ?😔 Merci pour votre intervention car maintenant, je sais que je n'ai pas de réflexes mais que je suis dans la débrouille ou même plus bas. 🤗
Je vous assure que vos vidéos m'inspire vraiment les gars moi même apprenant la programmation avec JavaScript depuis un moment déjà vos vidéos me pousse a le surpasser
Merci pour cette excellente vidéo une méthode de programmation. Je n'ai pas exactement la même vision de la programmation informatique. Dans le cadre des TMA: 1. L'analyse représente une grande part. 2. La correction c'est en général quelques lignes à modifier. 3. Tester 4. Documenter. Dans le cadre de projet: 1. Il vaut mieux passer du temps à analyser pour voir comment le projet va s'articuler. Limite passer par des produits comme Mindly. 2. Pisser du code propre bien indenté, sauter des lignes, faire des fonctions de 200 lignes maximums, avoir des noms de variables et de fonctions qui sont parlantes, ne pas hésiter de créer des un sous répertoire pour utiliser les fonctions réutilisables, ... 3. Tests unitaires de chaque fonction puis de chaque programme. 4. Tests sur l'ensemble de l'application développée. 5. Documenter
La notion de "quantité fois qualité" revient souvent et pour une une personne c'est le temps fois l'efficacité. Plus nous avons de compétences plus nous sommes puissant et la puissance donne le choix et donc la liberté. Continue de t'améliorer, ton cerveau est ton meilleur actif.
L'approche est semblable à celle d'un menuisier. Pour construire un meuble il faut acquérir une bonne représentation mentale de l'objet en 3D, puis penser à tout ce qui va aller dessus et dans quel ordre. Cela s'acquière avec du tps et bcp d'erreur. Bonne continuation à tpute personne qui s'engage sur le même chemin que toi.
J’ai commencé à coder il y a 6 mois, ça a été vraiment difficile, a chaque fois je pensais comprendre où maîtriser certaines choses je me rendais vite compte qu’il y avait plus à apprendre, j’avais l’impression de régresser, je pensais qu’il serait mieux d’apprend la base du computer science pour mieux comprendre, en écoutant d'autres softwares engineer américain, je me suis rendu compte que c’était ma façon d’apprendre à coder d’avoir essayé de tous mémoriser qui était mauvaise, maintenant j’apprends mieux. J'ai accepté d'oublier certaines choses et d'aller sur des forums ou Google pour ne renseigner
Je ne comprends pas lorsque vous dites "essayé de tous mémoriser" Voulez vous dire par là que la pratique est préférable ? Si oui, quels sont les rudiments à mémoriser avant de pouvoir passer à la pratique exclusive? SVP
@@jean-yves-thomasnkoengouam9285 Il faut que tu te choisisse un problème concret, stimulant et atteignable . En réalité rien ne doit faire obstacle à la pratique d'un débutant. C'est comme en musique : il n'y a pas besoin de connaissance pour débuter (juste de l'envie et du courage), cependant au fur et à mesure c'est bien de s'intéresser à la théorie musicale (rythme, harmonie...). Quelqu'un qui n'a que de la théorie mais pas de pratique ne sais rien faire, l'inverse est faux.
@@frerejacques9652 merci pour le conseil, mais en essayant d'utiliser Chapgpt, je me suis rendu compte qu'il m'est impossible de le faire car je suis au Cameroun.😌 Bonjour la mondialisation ! 🤧
Genial, ça fait 20 ans que je code mais sans aucune théorie, seulement de la pratique, ta vidéo est super intéressante et j'ai appris des trucs (notamment la "RAM cerveau")
En plus de la modularité il faut penser générique et comprendre l’abstraction pour éviter la duplication de code. Tu peux avoir pleins de modules mais si tu n’as pas d’abstraction alors ton code risque d’être dupliqué entre tes modules. Et enfin le typage devient très important pour garder un code solide, c’est pour ça qu’on passe du JavaScript à Typescript Il te reste peut être l’architecture Microservice à apprendre si ce n’est pas déjà fait ou même encore les designpatterns
Sympa la dimension que tu abordes désormais avec ta chaîne! Tu as l’air beaucoup plus clair dans tes objectifs mais aussi déterminé et ça se ressent donc congrats!
Salut super vidéo ! Comment a tu commencé ? ( Site internet , formation...) Sa fait longtemps que je te suis j'adore ton contenue tu m'inspire beaucoup !
Hello Florent, merci beaucoup pour cette excellente vidéo. J'ai beaucoup aimé et trouvé ça super intéressant. En tant que dév junior y'a vraiment plein d'aspects super intéressants qui sont abordés et de façon ludique même pour des non-connaisseurs. J'admire ton travail depuis longtemps et depuis que tu t'es lancé dans la prog je trouve que c'est encore plus intéressant. Merci pour ton travail
Superbe video, est-ce que tu pourrais faire une video sur la façon la plus optimale d'apprendre une nouvelle technologie (apprendre peu puis faire des projets ou bien une autre approche...)
Pour le TDD, c'est surtout qu'écrire les tests en premier et les faire passer au rouge, ça t'assure que tu n'aies pas écrit de faux-négatif.. Pour avoir écrit des tests après mon code, je suis parfois tombé sur des tests qui passaient toujours au vert, que mon code fonctionne ou non :)
Incroyable cette nouvelle competence que tu as acquise. Bon par contre j'ai un peu l'impression d'etre "expulsé" de la chaine au vu de la nouvelle thématique...
La remarque sur la Ram est super eloquente, perso c'est ma strategie d'optimisation numero 1 pour la productivite, peu importe le probleme, je le decompose toujours en petit module, je programme et teste chaque module, et une fois que j'ai confiance dans le code, bah construire sur ses modules devient facile, puisque j'ai pue a douter du module d'en dessous pour la suite.
Sur ceux qui savent s exprimer, ta conclusion pourrait plutôt être: "il n'a pas réellement de causalité" parce que en effet certains sont très bons et ne savent pas s'exprimer, mais en l'occurrence je sais aussi que des brutes en informatique sont capable de très bien communiquer en synthétisant parfaitement. C'est le cas de beaucoup de chercheurs que je connais, ou même d'expert en cybersécurité comme Geohot, qui sait par exemple super bien parler.
Pour le: un bon produit c'est 99% de débrouille et 1% de logique, alors oui et non... encore une fois si tu cherches à faire de l'ingénierie, le manque de rigueur peut deja: empatir sur la sécurité de ton logiciel (il ne faut pas oublier cet aspect!), mais aussi être tres lent ou gourmand en ressource (une mauvaise complexité !). Pour un développement plus bas niveau, un manque de rigueur et c'est la mort assurée niveau gestion mémoire, failles, bugs, etc
L'assembleur est la meilleure école de programmation parce que tu es obligé d'appliquer à la lettre tout ce que tu as dit sinon ça devient vite un enfer. Je rectifie juste un point sur ce que tu as dit, ce sont les commentaires du code, ils sont important pour détailler la fonction d'un bloc de lignes de code, ça évite de se replonger dans le programme à chaque fois que tu veux le modifier. Ce qui est vraiment nuisible ce sont les masses de commentaires en bout de chaque ligne, ça fait trop scolaire, c'est lourd et très ennuyeux à faire.
Bonjour, je constate que je suis pas le seul à mettre le paquet sur ce qu'il me tient à cœur. J'aimerais bien travailler avec vous, je suis développeur C++, Assembleur et Dart. Une chance que vous voyez mon commentaire, répondez moi ?🙂
Très bonne vidéo après je trouve que tu fais beaucoup de généralités qui ne sont pas forcément vraies. Vu ton discours j'ai l'impression que tu souhaites plutôt te lancer dans l'entreprenariat mais je te conseille vraiment de faire un saut par le salariat pour te faire une idée des vraies contraintes qu'un client t'impose et tu rendras vite compte qu'être bon, productif, qualitatif ne veut rien dire tout dépend du cahier des charges et de la demande du client. Ce qui fait la différence entre un bon ingénieur et un technicien c'est la capacité à comprendre la demande et à la retranscrire dans une solution technique adapté. Ecrire des lignes de codes beaucoup savent le faire ( d'ou l'expression pisser du code elle désigne l'idée que c'est un exercice assez commun ) par contre mené un projet à partir d'une simple idée assez flou d'un client, ça demande beaucoup plus de compétences que simplement savoir être un "bon" développeur.
Pour les nouveaux programmeurs le truc le plus important c'est de ne clairement PAS UTILISER CHATGPT SI VOUS NE COMPRENEZ PAS CE QUE VOUS COPIEZ. Sérieusement, ça détruit votre apprentissage, vous rends dépendant et quand vous copiez du code et que vous n'êtes pas capable d'expliquer à vos collègues c'est franchement malaisant. Aussi pour les nouveaux, ça prend souvent plus de temps de comprendre la logique optimisée de l'IA plutôt que d'apprendre les bases vous-mêmes.
@@ptipaco4617la programmation c’est vraiment énorme c’est comme si tu disais que tu voulais commencer la chimie ou la physique. Renseigne toi énormément d’abord sur les différents domaines.(web,data,algorithme,etc) certains demandes de la créativité et du temps (web), d’autres beaucoup de logique et de math(optimisation de programmes). Ensuite tu apprends un langage de programmation adapté au domaine sur lequel tu veux apprendre et finalement PRATIQUE. C’est un peu écrit à la va-vite mais j’espère que ça t’aideras.
Premier moi t je suis déjà pas d’accord avec toi il faut distinguer comme tu le dis ceux qui qui savent faire et ceux qui savent parler . Je pense que c’est simplement réducteur de dire que ceux qui savent parler ne savent pas faire. Je pense qu’il faut plus le voir comme le fait que ceux qui font connaissent le sujet dans sa précision et donc peuvent avoir du mal à prendre de la hauteur pour parler du sujet à un novice alors que ceux qui savent parler n’ont pas besoin de connaître un sujet en profondeur pour l’expliquer simplement ! Mais la nuance que tu fais mal est que une personne qui parle bien peu être très bon techniquement comment l’inverse ce n’est pas antinomique.
C'est réducteur, mais c'est très rare de trouver des gens qui sont très bons dans les 2, tout simplement car ça prend du temps de progresser dans les 2. Tu peux pas être bon à tout dans la vie. La communication, c'est un panel de métiers, comme pleins de métiers techniques. Sans compter que t'es dans un état d'esprit complètement différent quand tu essaies de progresser et quand tu essaies de transmettre, et que souvent parmis ceux qui progressent beaucoup, c'est souvent des addictions.
@@PierreMiniggio bien sûr le truc c’est que aujourd’hui en entreprise vous te vendre ou vendre ton travail (qui on supposera est bon techniquement) il faut arriver à savoir le présenter correctement et donc les compétences oratoires sont casi essentiel aujourd’hui, autant que les compétences techniques. Bien sûr par dans tous les métiers mais en tout cas de ce que j’en vois c’est quand même prépondérant
@@stiver6154 Alors, là tu parles d'un autre sujet. Il est vrai qu'en entreprise, il y a des situations où tu as plus intérêt à être bon techniquement, et d'autres où tu as plus intérêt à être bon oralement, et des fois un peu des 2. Mais tu vas très rarement trouver quelqu'un qui est à la fois très bon dans les 2. Et même le plus souvent (en tout cas en développement dans la majorité des boîtes), les rôles sont assez strictement distingués ce qui fait que tu peux ne jamais avoir avoir besoin de n'être même plus que giga nul à l'un des deux si t'es ok à l'autre. C'est juste des compétences différentes que tu peux apprendre. Et si tu veux être bon techniquement, plus t'avances et plus t'arriveras vite à un point où t'auras de plus en plus de mal à trouver des gens qui vont te communiquer tout de manière très bien formatté si tu veux accéder à de l'information très technique. Faut bien comprendre que ce qu'il a dit dans la vidéo, c'est pas que les techniques savent pas pas parler, et que les orateurs sont pas techniques. Il dit juste que les meilleurs techniques ne sont pas les meilleurs orateurs, et inversement.
Ce qu'il dit est aussi vrai qu'il est impossible de trouver une personne experte à la fois en génie mécanique et en médecine. Et pourtant, chaque expert, dans un de ces domaines, a tous les potentiels nécessaires pour l'être dans l'autre. 🙂
Oui et non, ça va peut être tuer des tâches que tu pourrais souvent donner à des débutants pour se faire la main, ce qui fait que ça va créer une barrière à l'entrée de connaissances encore plus grande pour arriver à monétiser ses compétences, mais le métier est très très loin de mourir, développeur c'est ça sera probablement un des derniers métiers techniques qui mourra une fois qu'on aura automatisé tous les autres métiers 😅.
@@denza_6786 Non. Au bout d'un moment faut comprendre qu'un programme ne peut rien faire de plus que ce qu'il est codé pour faire. C'est la base si vous vous prenez pour un développeur.
Après les crypto et la blochchaine tu compte te lancer dans le metaverse et le nft ou pas du tout ? Ou faire un habbo pour amoureux du net la ou on pourrait échanger et communiquer virtuellement des code etc ???
Ah oui musk hehe. Il est parti de qu’est-ce qu’un tunnel et au lieu de construire un métro efficient il a construit un tunnel à tesla bouché. Ou au lieu de faire un train à grande vitesse, il a parié sur une idée débile qui viole justement les lois de la physique comme il dit. Ou des fusées, oui ça c’est pas con, des fusées pour remplacer des avions supersoniques
C'est possible de se lancer dans le développement sans aucune base/connaissance ? Même pour quelqu'un qui n'est pas à l'aise avec un PC? Exemple un vieux pépé qui a connu la vie dans les champs et qui d'un coup se dit "oh pourquoi pas pisser du code"?😅 Je vous pose la question parce que j'avais un débat avec qqun qui me disait que n'importe qui peut coder en se formant, il n'y a rien d'innée ou de geek dans ça
Je pense à mon humble avis que ça dépend de plusieurs facteurs dont bcp bcp motivation et la raison intrinsèque qui incite la dit personne à vouloir apprendre à coder. En effet, partir de zéro demande beaucoup d'investissement en temps et en energie avec bcp de challenges/difficultés en cours de route qui peuvent amener la personne à laisser tomber et si elle n'est pas assez résiliente face à l'adversité je crains que le "Vieux pépé" ne pourrais pas devenir un bon developpeur. Néanmoins, je également la forte conviction que l'on apprendre presque tout ce que l'on souhaite et désir si l'on se trouve dans le bon environnement, qu'on se donne les moyens d'y arriver et que l'on persévère suffisament pour bénéficier des retombés positifs de notre investisement en temps et en energie durant la phase d'apprrentissage.
POV je suis en première année de prépa intégrée à Efrei Paris, et on j'ai mon partiel de python dans 1 semaine, ....... sur papier bruh j'ai tjr eu l'habitude dans toutes les matières de me débrouiller de comprendre comment résoudre quelque chose avec le minimum d'effort (maximisation de l'utilisation de l'utilisation de la calculatrice, chat gpt pour la prog etc)
@@ndlz justement, ca m'aide beaucoup plus que les poly de CM, en plus si je ne comprends pas une ligne, j'ai qu'à lui demander de m'expliquer, c'est génial !
Connaissez vous la grotte de Platon? Vous pouvez tout comprendre, ceux qui travaillent au fond de cette grotte sont antisociale ,et inversement Maintenant, serez vous assez intelligent pour sortir de cette grotte? Ou préférez vous y rester ?
franchement j'adore les vidéos, je trouve passionnant t'es aventures, par contre je suis désolé mais je comprend rien à ce que tu dis sur le codage, je comprend rien au codage
Concernant le 90% bug 10% logique je suis pas d'accord moi c'est l'inverse sur les sujets que je maitrise je code tout d'une traite sans rien tester et au bou de 4h je test et généralement les bugs que j'ai sont très mineur
Tes projets sont pas encore assez complexes alors, je connais 0 chercheur qui codent quelque chose de complexe et qui passe seulement un tout petit peu de temps pour que son projet marche
Exactement, la logique et la réfléction fait que quand tu codes y'a tres peu de bug .... il faut mieux refléchir plus que de coder ..... ceux qui codent sans trop réfléchir c'est des bugs assurés et surtout la moins bonne solution. J'ai connu une personne qui savait tout sur tout, et quand il codait 98% des choses bugués et ne marchés pas. Rentrer dans 10 000 programmes qui parfois font 100 000 lignes de codes sans prendre le temps de réfléchir tu met l'entreprise en danger
Ptdrrrrrr lire du code source de Linux ? Ca ma fait rire, autant des petits programmes c’est faisable, autant pour un OS c’est réservé à genre 0.1% des développeurs mondiaux hein
@@walidmkw Justement, le systeme d'exploitation c'est pas juste le kernel et quand on configure / personnalise son Linux, évidemment qu'il ne s'afit pas du kernel
Juste parfait, en 1 an t'as parfaitement compris les directions où il faut creuser pour avancer en code & produire des choses.
Chapeau bas.
Et ça fait plaisir de trouver ça sur une chaîne où ça a des chances d'inspirer des gens qui vont commencer à apprendre à coder, tu pointes les bons chemins ! 😁
Pas mal comme vidéo, tu as capté une bonne partie des éléments que doivent connaitre les développeurs expérimentés. Je mettrais tout de même plus de nuances sur tes 2 derniers points :
- La productivité est quelque chose qui est extrêmement compliqué à quantifier dans le domaine de la programmation. Est-ce que c'est le nombre de lignes de code pondues par jour ? La capacité de résoudre un problème ? De fournir le code le plus modulaire ?De répondre aux attentes du client de la manière la plus efficace ?
Probablement un peu de tout ça, mais chacune de ces qualités ne sont généralement pas partagées par les mêmes personnes (en tout cas sur un projet d'envergure). C'est pour ça que les métiers de architectes, analystes développeurs, testeurs,... existent. Dans les faits, en tant que professionnel, tu seras amené à toucher à tout ça mais il y a une vrai expertise dans chacun de ces métiers qui demandent des années d'expérience (et encore ici, je ne fais qu'effleurer la surface).
Pour les lignes de code, c'est encore plus compliqué à jauger, tant cela peut varier selon le problème traité et leur complexité. Certains protocoles, comme l'échange de clé de Diffie-Hellman sont très simple à implémenter (quelques centaines de lignes tout au plus) mais ont encore un énorme impact sur la cryptographie "Pre-quantum". Néanmoins, il a fallu beaucoup de travail en amont en informatique théorique pour déterminer que cette méthode était sécurisée pour échanger des clés. Pour rester dans le domaine de la cryptographie, il est bon de rappeler que non, les gens qui ont le plus d'impact ne sont pas "les superstars des GAFAM" mais sont souvent avant tout des chercheurs universitaires passionnés. Je finirais ce point en reprenant cette phrase qu'on attribue à Ken Thompson (le créateur des systèmes UNIX) "One of my most productive days was throwing away 1,000 lines of code".
- Sur ton dernier point, c'est une grave erreur, à mon sens, de réduire un projet à une simple question de coût. En project management, on parle plutôt du triangle Cost-Time-Scope (+ la qualité qui peut-être plus ou moins arbitraire). Je te laisse te renseigner sur ce point car la gestion de projet, c'est pas ma passion. Je vais juste ajouter un point sur la sécurité (mon domaine) : toutes les personnes de l'industrie te diront que c'est irresponsable de ne pas inclure (du tout) la sécurité dans ton processus et que celle-ci a un prix certain. Le problème, c'est que la sécurité n'a pas d'intérêt objectif pour une entreprise (pas de ROI) et ce n'est que lorsque le mal est fait qu'on peut voir l'ampleur des dégâts. La sécurité informatique devrait être considéré comme quelque chose dont l'intérêt est supérieur à son coût (comme le secteur public de la santé par exemple). Il est donc nécessaire à mon sens de sortir de ce paradigme du "Limiter les coûts à tout prix".
Sur la partie des coûts , je suis absolument d’accord
C’est d’ailleurs l’une des bases des cabinets d’investissements , il achète toutes les boîtes d’un secteur de niche qui a un potentiel énorme car ils savent que l’une d’entre elles va forcément exploser
Réponse super interessante! Merci
Merci pour ces précisions.
Je n'ai pas lu de commentaire aussi intéressant depuis très longtemps. Est-ce que tu aurais quelques bonnes ressources pour ce familiariser avec la gestion de projet (livres, vidéos, sites...) ?
@@frerejacques9652 en termes de livres, tu as les 2 Bibles du domaine : le Project Management Body Of Knowledge du Project Management Institute et Prince2 que tu devrais pouvoir chopper gratuitement, mais bon ça reste 2 grosses briques pas forcément digestes si tu veux feuilleter par simple curiosité.
Je te recommande à la place la page wikipedia de la gestion de projet. Si tu es à l'aise avec l'anglais, je te conseille sa version originale "Project management", que je trouve bien plus illustrée et détaillée (avec de nombreuses références vers d'autres articles) que la version française. En termes de vidéos, je ne pourrai pas te répondre, je n'en connais pas.
Je te conseillerais tout de même d'être prudent (surtout avec le format vidéo) car la gestion de projet est gangrenée par le storytelling et le marketing notamment quand tu vas entendre parler des méthodes agiles, scrum, XP, ... Sur ce dernier point, encore une fois, la page wikipedia prend bien plus de recul et s'attarde (au moins un minimum) sur les différentes critiques qui ont été amenées à ces méthodes
Salut, j'ai une douzaine d'années d'expérience dans le dev, j'ai vu beaucoup de profils différents de développeurs, lead et architectes durant toutes ces années, et je me permets de te dire que je trouve que tu balances un énorme poncif d'entrée. On retrouve pléthore d'excellent lead dev ou dev senior, excellents orateurs et pédagogues. Le cliché des geeks introvertis qui sont meilleurs que ceux plus à l'aise socialement, il est faux et révolu depuis les années 2010. La vérité c'est qu'il n'y a pas de règle de ce côté là, on trouve de tout et aucun profil psychologique n'a le monopole du génie dans le dev. C'est bien de se méfier de ceux qui parlent "trop" mais attention avec tes "jamais".
Tu as eu une excellente approche de repartir de zéro à chaque fois pour faire mieux, c'est vraiment en ce moment dans ta carrière que tu as le temps de faire les choses bien pour prendre les bons réflexes et les bonnes habitudes. Le métier de dev, c'est 99% non pas de débrouille mais de réflexes, et ce sont ces réflexes et bonnes pratiques acquis qui font que l'on va de plus en plus vite à faire de la qualité. Il faut tout miser sur comment acquérir ces réflexes et ça passe par la répétition et la confrontation avec de nouvelles choses à implémenter en permanence.
J'aime beaucoup comment tu présentes le TDD et pourquoi ça vous aurait aidé à aller plus vite, ce cas complexe qui aurait été traité en itérant je le trouve idéal pour l'introduire.
Lol 2010 c'est l'année où t'as commencé à bosser c'est ça ?
Putain merci, je me suis dis direct la même chose, le gars il balance d'entrée un gros cliché tellement rincé que ça le discrédite d'emblé.
merci, ça m'a choquée qu'il raconte ça dès le départ. Je travaille dans ce milieux (même si je ne suis pas dev) et je constate bien également qu'il y a des développeurs timides et des lead Dev, et le lead dev sait à la fois coder, former aux bonnes pratiques de dev et s'exprimer sans problème. Bref, la règle en matière de crédibilité, c'est d'éviter les raisonnements à l'emporte-pièce, et donc les 'jamais' ainsi que les 'quasiment jamais' qui ne sont que des variantes rhétoriques ;)
Si je peux me permettre la suite,
J'ai 37 ans et je suis un débutant bêta dans la programmation, notamment sur l'IA.
Votre propos reflète votre niveau parce que vous oubliez qu'il s'adresse aux novices.
Lorsqu'il fait une telle introduction, c'est pour clairement aider les novices à se situer dans le domaine, c'est-à-dire est-ce qu'il veut devenir un codeur pro à temps plein ou avoir juste les rudiments pour faire du marketing ou diriger une équipe. Bref, il est question là de comprendre qu'on ne peut être dans le back office et le front office au même moment, confère tous les entrepreneurs célèbres de la high-tech, qui ont commencé dans le back office pour finir dans le front office.
Ensuite, lorsqu'il parle de "débrouille" c'est encore adressé aux novices. Effectivement, avec le temps, ces "débrouilles" vont se tranformer en "réflexes".
Pour être franc, sa vidéo m'a beaucoup éclairci la vision de l'apprentissage de la programmation car elle répond à beaucoup de blocus surtout que je le fais en autodidacte. Sauf que mon âge est le dernier blocus, vais-je y arriver à mon âge ?😔
Merci pour votre intervention car maintenant, je sais que je n'ai pas de réflexes mais que je suis dans la débrouille ou même plus bas. 🤗
Je vous assure que vos vidéos m'inspire vraiment les gars moi même apprenant la programmation avec JavaScript depuis un moment déjà vos vidéos me pousse a le surpasser
Merci pour cette excellente vidéo une méthode de programmation.
Je n'ai pas exactement la même vision de la programmation informatique.
Dans le cadre des TMA:
1. L'analyse représente une grande part.
2. La correction c'est en général quelques lignes à modifier.
3. Tester
4. Documenter.
Dans le cadre de projet:
1. Il vaut mieux passer du temps à analyser pour voir comment le projet va s'articuler. Limite passer par des produits comme Mindly.
2. Pisser du code propre bien indenté, sauter des lignes, faire des fonctions de 200 lignes maximums, avoir des noms de variables et de fonctions qui sont parlantes, ne pas hésiter de créer des un sous répertoire pour utiliser les fonctions réutilisables, ...
3. Tests unitaires de chaque fonction puis de chaque programme.
4. Tests sur l'ensemble de l'application développée.
5. Documenter
La notion de "quantité fois qualité" revient souvent et pour une une personne c'est le temps fois l'efficacité. Plus nous avons de compétences plus nous sommes puissant et la puissance donne le choix et donc la liberté. Continue de t'améliorer, ton cerveau est ton meilleur actif.
L'approche est semblable à celle d'un menuisier. Pour construire un meuble il faut acquérir une bonne représentation mentale de l'objet en 3D, puis penser à tout ce qui va aller dessus et dans quel ordre. Cela s'acquière avec du tps et bcp d'erreur. Bonne continuation à tpute personne qui s'engage sur le même chemin que toi.
Merci ! Bonne année Florent, content de te revoir devant la caméra et plus uniquement derriere.
J’ai commencé à coder il y a 6 mois, ça a été vraiment difficile, a chaque fois je pensais comprendre où maîtriser certaines choses je me rendais vite compte qu’il y avait plus à apprendre, j’avais l’impression de régresser, je pensais qu’il serait mieux d’apprend la base du computer science pour mieux comprendre, en écoutant d'autres softwares engineer américain, je me suis rendu compte que c’était ma façon d’apprendre à coder d’avoir essayé de tous mémoriser qui était mauvaise, maintenant j’apprends mieux.
J'ai accepté d'oublier certaines choses et d'aller sur des forums ou Google pour ne renseigner
C'est la base de chercher sur Google
Je ne comprends pas lorsque vous dites "essayé de tous mémoriser"
Voulez vous dire par là que la pratique est préférable ? Si oui, quels sont les rudiments à mémoriser avant de pouvoir passer à la pratique exclusive? SVP
@@jean-yves-thomasnkoengouam9285 Il faut que tu te choisisse un problème concret, stimulant et atteignable . En réalité rien ne doit faire obstacle à la pratique d'un débutant. C'est comme en musique : il n'y a pas besoin de connaissance pour débuter (juste de l'envie et du courage), cependant au fur et à mesure c'est bien de s'intéresser à la théorie musicale (rythme, harmonie...). Quelqu'un qui n'a que de la théorie mais pas de pratique ne sais rien faire, l'inverse est faux.
@@frerejacques9652 merci pour le conseil, mais en essayant d'utiliser Chapgpt, je me suis rendu compte qu'il m'est impossible de le faire car je suis au Cameroun.😌
Bonjour la mondialisation ! 🤧
Donc si je comprends bien, il faut plutôt chercher a comprendre que de mémoriser
Genial, ça fait 20 ans que je code mais sans aucune théorie, seulement de la pratique, ta vidéo est super intéressante et j'ai appris des trucs (notamment la "RAM cerveau")
Ta vidéo est super clair et je me reconnais dans ce que tu expliques, je me dis que je me suis pas trop égaré étant moi même parti de rien
En plus de la modularité il faut penser générique et comprendre l’abstraction pour éviter la duplication de code. Tu peux avoir pleins de modules mais si tu n’as pas d’abstraction alors ton code risque d’être dupliqué entre tes modules.
Et enfin le typage devient très important pour garder un code solide, c’est pour ça qu’on passe du JavaScript à Typescript
Il te reste peut être l’architecture Microservice à apprendre si ce n’est pas déjà fait ou même encore les designpatterns
J'ajouterai : Il est souvent très difficile de faire simple !
Merci pour ce retour détaillé !
Sympa la dimension que tu abordes désormais avec ta chaîne! Tu as l’air beaucoup plus clair dans tes objectifs mais aussi déterminé et ça se ressent donc congrats!
7:25 les tests peuvent aussi servir de docs ce qui est bien pratique par moment
Salut super vidéo ! Comment a tu commencé ? ( Site internet , formation...) Sa fait longtemps que je te suis j'adore ton contenue tu m'inspire beaucoup !
Hello Florent, merci beaucoup pour cette excellente vidéo. J'ai beaucoup aimé et trouvé ça super intéressant. En tant que dév junior y'a vraiment plein d'aspects super intéressants qui sont abordés et de façon ludique même pour des non-connaisseurs.
J'admire ton travail depuis longtemps et depuis que tu t'es lancé dans la prog je trouve que c'est encore plus intéressant. Merci pour ton travail
Superbe video, est-ce que tu pourrais faire une video sur la façon la plus optimale d'apprendre une nouvelle technologie (apprendre peu puis faire des projets ou bien une autre approche...)
Il faut d’abord choisir un problème à résoudre, c’est en le résolvant qu’on apprend des nouvelles techno.
t'es déjà bien avancé pour 1 an de dev c'est cool à voir
bravo pour cette maturité au bout d'un an de code tu as une sacré vision globale
Instructif et carré comme d'habitude. 👌🏻💪🏻
Merci pour ce retour d’expérience
Pour le TDD, c'est surtout qu'écrire les tests en premier et les faire passer au rouge, ça t'assure que tu n'aies pas écrit de faux-négatif..
Pour avoir écrit des tests après mon code, je suis parfois tombé sur des tests qui passaient toujours au vert, que mon code fonctionne ou non :)
J’ai kiffé ton partage 👌🏾🙏🏾👍🏾
Cette vidéo mérite plus de visibilité !
Incroyable cette nouvelle competence que tu as acquise.
Bon par contre j'ai un peu l'impression d'etre "expulsé" de la chaine au vu de la nouvelle thématique...
Video top, je vais bien attaquer mon cours d'informatique (2ème année ingénieur)
Super vidéo 🔥
Super, surtout la fin j’ai adoré
La remarque sur la Ram est super eloquente, perso c'est ma strategie d'optimisation numero 1 pour la productivite, peu importe le probleme, je le decompose toujours en petit module, je programme et teste chaque module, et une fois que j'ai confiance dans le code, bah construire sur ses modules devient facile, puisque j'ai pue a douter du module d'en dessous pour la suite.
ça fait plaisir !
Sur ceux qui savent s exprimer, ta conclusion pourrait plutôt être: "il n'a pas réellement de causalité" parce que en effet certains sont très bons et ne savent pas s'exprimer, mais en l'occurrence je sais aussi que des brutes en informatique sont capable de très bien communiquer en synthétisant parfaitement. C'est le cas de beaucoup de chercheurs que je connais, ou même d'expert en cybersécurité comme Geohot, qui sait par exemple super bien parler.
Bien sur, c'est une généralité. Geohot est excellent sur ce point en effet
J'adore vos aventures !
giga propre mec , merci
Salut, bravo pour ce que tu fais :) Pour toi, c'est quoi la meilleure façon d'apprendre le dev? et quel langage pour commencer ?
Pour le: un bon produit c'est 99% de débrouille et 1% de logique, alors oui et non... encore une fois si tu cherches à faire de l'ingénierie, le manque de rigueur peut deja: empatir sur la sécurité de ton logiciel (il ne faut pas oublier cet aspect!), mais aussi être tres lent ou gourmand en ressource (une mauvaise complexité !). Pour un développement plus bas niveau, un manque de rigueur et c'est la mort assurée niveau gestion mémoire, failles, bugs, etc
pile quand j'en ai besoin
Le pourquoi je suis full Linux Chez moi, et en Windows que au taff (Vm linux s'il le faut)
Moi ausi je suis une codeuse et suis absolument daccord avec toi !
enfin le retour
tu parles de papier sur la cryptographie, où trouves tu ces papiers ?
force a toi flo !
L'assembleur est la meilleure école de programmation parce que tu es obligé d'appliquer à la lettre tout ce que tu as dit sinon ça devient vite un enfer. Je rectifie juste un point sur ce que tu as dit, ce sont les commentaires du code, ils sont important pour détailler la fonction d'un bloc de lignes de code, ça évite de se replonger dans le programme à chaque fois que tu veux le modifier. Ce qui est vraiment nuisible ce sont les masses de commentaires en bout de chaque ligne, ça fait trop scolaire, c'est lourd et très ennuyeux à faire.
Bonjour, je constate que je suis pas le seul à mettre le paquet sur ce qu'il me tient à cœur. J'aimerais bien travailler avec vous, je suis développeur C++, Assembleur et Dart. Une chance que vous voyez mon commentaire, répondez moi ?🙂
Vraiment intéressant
J’ai absolument rien compris à cette vidéo mais je l’ai regardée jusqu’au bout 😅
Sérieux ?!? 😅
Très bonne vidéo
J’ai l’impression que tu parles de mieux en mieux
Allez petite question pour les développeurs ici et le créateur de la chaîne : est-ce que QUIC est un remplacement pour TCP ?
Personnellement je ne pense pas, je dirais que l'avenir est du coté des réseaux centrés sur les donnés, ICN, NDN etc
Très bonne vidéo après je trouve que tu fais beaucoup de généralités qui ne sont pas forcément vraies. Vu ton discours j'ai l'impression que tu souhaites plutôt te lancer dans l'entreprenariat mais je te conseille vraiment de faire un saut par le salariat pour te faire une idée des vraies contraintes qu'un client t'impose et tu rendras vite compte qu'être bon, productif, qualitatif ne veut rien dire tout dépend du cahier des charges et de la demande du client.
Ce qui fait la différence entre un bon ingénieur et un technicien c'est la capacité à comprendre la demande et à la retranscrire dans une solution technique adapté. Ecrire des lignes de codes beaucoup savent le faire ( d'ou l'expression pisser du code elle désigne l'idée que c'est un exercice assez commun ) par contre mené un projet à partir d'une simple idée assez flou d'un client, ça demande beaucoup plus de compétences que simplement savoir être un "bon" développeur.
Vrai question qu'aurai donné OpenAI (chatGPT) dans ton entrainement de code pendant 1 an si tu l'avais eu avant ? 🤔
De quelle question vous parlez, SVP ?🤔
En mon sens, il n'a fait que partager son bilan après 1 an de programmation en freelance.☺️
@@jean-yves-thomasnkoengouam9285 si vous ne connaissez pas openAi ou chatGPT c’est trop long à expliquer renseignez vous, vous n’allez pas être déçu !
De quoi vis-tu Florent ?
Vraiment pas mal.
Que répondrais-tu à ceux qui disent que Bitcoin est un Ponzi ?
super vidéo !
Excellente vidéo
Pour les nouveaux programmeurs le truc le plus important c'est de ne clairement PAS UTILISER CHATGPT SI VOUS NE COMPRENEZ PAS CE QUE VOUS COPIEZ. Sérieusement, ça détruit votre apprentissage, vous rends dépendant et quand vous copiez du code et que vous n'êtes pas capable d'expliquer à vos collègues c'est franchement malaisant. Aussi pour les nouveaux, ça prend souvent plus de temps de comprendre la logique optimisée de l'IA plutôt que d'apprendre les bases vous-mêmes.
Salut
J’aimerais me lancer dans la programmation mais j’ai aucune base, t’aurais des conseils pour commencer ?
@@ptipaco4617Utilise mimo
Commentaire très utile
@@ptipaco4617 lancer un projet 👍
@@ptipaco4617la programmation c’est vraiment énorme c’est comme si tu disais que tu voulais commencer la chimie ou la physique. Renseigne toi énormément d’abord sur les différents domaines.(web,data,algorithme,etc) certains demandes de la créativité et du temps (web), d’autres beaucoup de logique et de math(optimisation de programmes). Ensuite tu apprends un langage de programmation adapté au domaine sur lequel tu veux apprendre et finalement PRATIQUE. C’est un peu écrit à la va-vite mais j’espère que ça t’aideras.
Super vidéo
Premier moi t je suis déjà pas d’accord avec toi il faut distinguer comme tu le dis ceux qui qui savent faire et ceux qui savent parler . Je pense que c’est simplement réducteur de dire que ceux qui savent parler ne savent pas faire. Je pense qu’il faut plus le voir comme le fait que ceux qui font connaissent le sujet dans sa précision et donc peuvent avoir du mal à prendre de la hauteur pour parler du sujet à un novice alors que ceux qui savent parler n’ont pas besoin de connaître un sujet en profondeur pour l’expliquer simplement ! Mais la nuance que tu fais mal est que une personne qui parle bien peu être très bon techniquement comment l’inverse ce n’est pas antinomique.
C'est réducteur, mais c'est très rare de trouver des gens qui sont très bons dans les 2, tout simplement car ça prend du temps de progresser dans les 2.
Tu peux pas être bon à tout dans la vie. La communication, c'est un panel de métiers, comme pleins de métiers techniques.
Sans compter que t'es dans un état d'esprit complètement différent quand tu essaies de progresser et quand tu essaies de transmettre, et que souvent parmis ceux qui progressent beaucoup, c'est souvent des addictions.
@@PierreMiniggio bien sûr le truc c’est que aujourd’hui en entreprise vous te vendre ou vendre ton travail (qui on supposera est bon techniquement) il faut arriver à savoir le présenter correctement et donc les compétences oratoires sont casi essentiel aujourd’hui, autant que les compétences techniques. Bien sûr par dans tous les métiers mais en tout cas de ce que j’en vois c’est quand même prépondérant
@@stiver6154 Alors, là tu parles d'un autre sujet.
Il est vrai qu'en entreprise, il y a des situations où tu as plus intérêt à être bon techniquement, et d'autres où tu as plus intérêt à être bon oralement, et des fois un peu des 2.
Mais tu vas très rarement trouver quelqu'un qui est à la fois très bon dans les 2.
Et même le plus souvent (en tout cas en développement dans la majorité des boîtes), les rôles sont assez strictement distingués ce qui fait que tu peux ne jamais avoir avoir besoin de n'être même plus que giga nul à l'un des deux si t'es ok à l'autre.
C'est juste des compétences différentes que tu peux apprendre.
Et si tu veux être bon techniquement, plus t'avances et plus t'arriveras vite à un point où t'auras de plus en plus de mal à trouver des gens qui vont te communiquer tout de manière très bien formatté si tu veux accéder à de l'information très technique.
Faut bien comprendre que ce qu'il a dit dans la vidéo, c'est pas que les techniques savent pas pas parler, et que les orateurs sont pas techniques.
Il dit juste que les meilleurs techniques ne sont pas les meilleurs orateurs, et inversement.
Ce qu'il dit est aussi vrai qu'il est impossible de trouver une personne experte à la fois en génie mécanique et en médecine. Et pourtant, chaque expert, dans un de ces domaines, a tous les potentiels nécessaires pour l'être dans l'autre. 🙂
Obligé d'expliquer le ZKP dans une prochaine vidéo !!!
Je suis débutant et je souhaite apprendre à coder, par quoi me recommandez vous de commencer?
Je ne suis pas un pro, mais je vais répondre en disant: L'algorithme.🤗
Que les pros viennent me dire si j'ai tout bon 😏
Salut Flo, tu codes avec quel langage généralement ?
Salut, est-ce vrai que le métier va être remplacé par L'IA ?
Non, dans le meilleur des cas l'IA va servir d'assistance
@@bossgd100 à voir dans 10 ans
@@denza_6786 programmer c'est penser, on verra si dans 10 ans on a une machine qui pense ;)
Oui et non, ça va peut être tuer des tâches que tu pourrais souvent donner à des débutants pour se faire la main, ce qui fait que ça va créer une barrière à l'entrée de connaissances encore plus grande pour arriver à monétiser ses compétences, mais le métier est très très loin de mourir, développeur c'est ça sera probablement un des derniers métiers techniques qui mourra une fois qu'on aura automatisé tous les autres métiers 😅.
@@denza_6786 Non. Au bout d'un moment faut comprendre qu'un programme ne peut rien faire de plus que ce qu'il est codé pour faire. C'est la base si vous vous prenez pour un développeur.
Après les crypto et la blochchaine tu compte te lancer dans le metaverse et le nft ou pas du tout ? Ou faire un habbo pour amoureux du net la ou on pourrait échanger et communiquer virtuellement des code etc ???
la psychiatrie
@@merwane2604 comment Ça la psychiatrie ??? 🤔🤔🤔
Bravo merci
Tu parles trop bien ! Mais du coup j'ai un doute sur tes qualités de codeur...
Pourquoi tu as quitté l'atelier ?
Tu pourrais parler de la programmation fonctionnelle ?
Si tu ne fais pas d'allergie à Haskell, il y a la chaîne de nokomprendo.
Lourd
J4ai un idée de bussiness révolutionnaire
j'aime bien ton contenue
Ah oui musk hehe. Il est parti de qu’est-ce qu’un tunnel et au lieu de construire un métro efficient il a construit un tunnel à tesla bouché. Ou au lieu de faire un train à grande vitesse, il a parié sur une idée débile qui viole justement les lois de la physique comme il dit.
Ou des fusées, oui ça c’est pas con, des fusées pour remplacer des avions supersoniques
Vous bossez sur des API ?
Code François
LOURD 🙃
Génie
Super video
Salut, quels langages as-tu appris en 1 an ? Et quel a été le plus facile/difficile ? Super vidéo en tout cas !
Pour le langage j'imagine que c'est du solidity, c'est ce qui est majoritairement utilisé en crypto
Pour compléter la réponse de Raphaël, ils ont fait du HTML/CSS et beaucoup de JS pour leur projet Moonolith aussi !
Interessant
Parfait
✊
La barre en bas à droite me stress énormément, je ne vois que ça
Et la muscu ?
on est sur le dossier
C'est possible de se lancer dans le développement sans aucune base/connaissance ? Même pour quelqu'un qui n'est pas à l'aise avec un PC? Exemple un vieux pépé qui a connu la vie dans les champs et qui d'un coup se dit "oh pourquoi pas pisser du code"?😅
Je vous pose la question parce que j'avais un débat avec qqun qui me disait que n'importe qui peut coder en se formant, il n'y a rien d'innée ou de geek dans ça
Je pense à mon humble avis que ça dépend de plusieurs facteurs dont bcp bcp motivation et la raison intrinsèque qui incite la dit personne à vouloir apprendre à coder. En effet, partir de zéro demande beaucoup d'investissement en temps et en energie avec bcp de challenges/difficultés en cours de route qui peuvent amener la personne à laisser tomber et si elle n'est pas assez résiliente face à l'adversité je crains que le "Vieux pépé" ne pourrais pas devenir un bon developpeur.
Néanmoins, je également la forte conviction que l'on apprendre presque tout ce que l'on souhaite et désir si l'on se trouve dans le bon environnement, qu'on se donne les moyens d'y arriver et que l'on persévère suffisament pour bénéficier des retombés positifs de notre investisement en temps et en energie durant la phase d'apprrentissage.
Pas mal, y a du progrès
1:58 c'est benjamin code à gauche ??
Non c'est moi
T plus avc missor ?
Prk t plus a l’atelier 😢
Cool😊
super
POV je suis en première année de prépa intégrée à Efrei Paris, et on j'ai mon partiel de python dans 1 semaine, ....... sur papier bruh
j'ai tjr eu l'habitude dans toutes les matières de me débrouiller de comprendre comment résoudre quelque chose avec le minimum d'effort (maximisation de l'utilisation de l'utilisation de la calculatrice, chat gpt pour la prog etc)
C'est une étape à passer, courage
Pour ChatGPT attention à que cela ne t'empeche pas de comprendre
@@ndlz justement, ca m'aide beaucoup plus que les poly de CM, en plus si je ne comprends pas une ligne, j'ai qu'à lui demander de m'expliquer, c'est génial !
@@charlesp5419 plus que les polys mais moins que les projets persos
@@ndlz ca c'est clair
Connaissez vous la grotte de Platon?
Vous pouvez tout comprendre, ceux qui travaillent au fond de cette grotte sont antisociale ,et inversement
Maintenant, serez vous assez intelligent pour sortir de cette grotte?
Ou préférez vous y rester ?
👍👍👍👍👍👍👍👍👍👍
cool
👍
franchement j'adore les vidéos, je trouve passionnant t'es aventures, par contre je suis désolé mais je comprend rien à ce que tu dis sur le codage, je comprend rien au codage
Concernant le 90% bug 10% logique je suis pas d'accord
moi c'est l'inverse sur les sujets que je maitrise je code tout d'une traite sans rien tester et au bou de 4h je test et généralement les bugs que j'ai sont très mineur
Tes projets sont pas encore assez complexes alors, je connais 0 chercheur qui codent quelque chose de complexe et qui passe seulement un tout petit peu de temps pour que son projet marche
@@unbaronvnr1760 sur les sujets que je maitrise
Exactement, la logique et la réfléction fait que quand tu codes y'a tres peu de bug .... il faut mieux refléchir plus que de coder ..... ceux qui codent sans trop réfléchir c'est des bugs assurés et surtout la moins bonne solution. J'ai connu une personne qui savait tout sur tout, et quand il codait 98% des choses bugués et ne marchés pas. Rentrer dans 10 000 programmes qui parfois font 100 000 lignes de codes sans prendre le temps de réfléchir tu met l'entreprise en danger
🐧
Ptdrrrrrr lire du code source de Linux ? Ca ma fait rire, autant des petits programmes c’est faisable, autant pour un OS c’est réservé à genre 0.1% des développeurs mondiaux hein
Y a pas que le kernel, tu peux faire des scripts pour personnaliser Gnome par exemple
@@ndlz bah il parlais de l’OS, sinon dans ce cas jsuis d’accord
@@walidmkw Justement, le systeme d'exploitation c'est pas juste le kernel et quand on configure / personnalise son Linux, évidemment qu'il ne s'afit pas du kernel
@@ndlz ah je vois, c’est vrai maintenant dis comme ça, moi je pensais directement au kernels en parlant des système d’exploitation Linux
19:22 ma mère
Belle leçon ! à diffuser dans les écoles privées d'info (bien trop chère) ahah
Et certainement qu'on veut du spoil sur ce projet ! Self-custodial ?😉
Self-custodial.
Wesh gros
Presque first