https://fr.news.hada.io/topic?id=19168
C’est une recherche à laquelle l’IA n’aurait probablement jamais pensé.
Je suis d’accord avec l’essentiel de l’article.
Je pense qu’il y a aussi beaucoup de bons ingénieurs en Corée, mais je ressens moi aussi souvent une certaine frustration à cause de la taille du marché.
J’aurais aimé qu’un acteur comme FuriosaAI réussisse vraiment.
J’ai aussi contribué à la partie gestion mémoire du noyau Linux, et je pense avoir une certaine compréhension du fonctionnement bas niveau. Mais quand je vois qu’au final je fais malgré moi un travail assez éloigné du développement, je me dis qu’il faut peut-être agir à l’inverse de cet article pour devenir un ingénieur qui réussit.
Suivre rapidement les nouvelles technologies
Penser au marché plutôt qu’à sa curiosité personnelle
Mieux savoir se mettre en valeur que s’autocritiquer
Se concentrer sur les tests de code plutôt que sur les principes ou la progression
En rentrant au pays, je me suis rendu compte que le marché coréen est trop petit et la concurrence trop forte, donc il y a peu d’entreprises ou de postes où l’on peut se concentrer sur le développement. Et comme tout le monde se bat pour obtenir ces rares places, on a finalement l’impression qu’il faut se concentrer sur ce qui attire le plus l’attention pour pouvoir faire le développement qu’on veut vraiment faire.
« Nous n’avons pas besoin d’un élève A+ capable de répondre à toutes les questions
Ce que nous voulons, c’est un élève B capable de voir et de poser des questions sur ce que les autres ont manqué »
En voyant ça, j’ai tout de suite pensé que j’étais justement un élève B, mais que les grandes entreprises ne regardent et ne recrutent que des élèves A+.
Il n’y a pas si longtemps, j’ai animé au bureau un séminaire dans le cadre d’une étude du langage Kotlin, et je me souviens que la réaction avait été bonne parce que j’avais choisi de l’expliquer en le comparant au langage C++, principalement utilisé dans l’équipe. En réalité, je n’utilise presque jamais le C++, et les membres de l’équipe découvraient Kotlin pour la première fois, mais j’ai eu l’impression que, à bien des égards, cela avait aidé tout le monde à progresser.
Il semble que le dernier point de la traduction du résumé des avis sur Hacker News, « il pourrait être erroné de supposer que la productivité du logiciel n’a pas été multipliée par 5 à 10 », soit une mauvaise traduction. À la lecture du texte original, un résumé plus raisonnable serait plutôt quelque chose comme : « affirmer que la productivité du logiciel a été multipliée par 5 à 10 repose sur des hypothèses erronées concernant le gain de productivité ».
Oui, je suis d’accord. Il faut aussi savoir se rendre visible, et ce serait bien que les personnes qui donnent se fassent souvent des shout-outs entre elles. La culture d’entreprise elle-même devrait l’encourager.
> La plupart des programmeurs ne savent pas comment utiliser efficacement les outils LLM, ou ne s’y intéressent pas.
Étonnamment, beaucoup de développeurs autour de moi ne s’intéressent pas vraiment à la technologie. Ils passent la majeure partie de leur temps à consommer mécaniquement des YouTube Shorts nouveaux ou répétitifs.
On dirait que le tweet n’existe plus, ou que l’original a été supprimé.
J’aimerais bien l’essayer, mais même si c’est en preview, c’est payant et il n’y a pas de période d’essai, snif.
En cherchant, on voit aussi des gens dire qu’ils ont dépensé 5 dollars pour seulement quelques requêtes, donc j’imagine que ça dépend aussi de la taille du code du projet.
Il y a beaucoup de points intéressants, tant du point de vue des RH que de la culture d’entreprise.
Comme je ne connaissais pas bien le sujet, j’ai regardé, et il semble que le backdoor reference check corresponde à une vérification de réputation non désignée. Je le laisse ici au cas où d’autres personnes comme moi se poseraient la question.
Ce manus qui aurait fourni son propre code source !!
https://fr.news.hada.io/topic?id=19168
C’est une recherche à laquelle l’IA n’aurait probablement jamais pensé.
Je suis d’accord avec l’essentiel de l’article.
Je pense qu’il y a aussi beaucoup de bons ingénieurs en Corée, mais je ressens moi aussi souvent une certaine frustration à cause de la taille du marché.
J’aurais aimé qu’un acteur comme FuriosaAI réussisse vraiment.
Lecture intéressante, merci.
Waouh… je connais quelqu’un qui ressemble énormément à ce portrait, je devrais lui partager.
Merci pour ce très bon article.
Je comprends tout à fait. À ma manière, j’ai tendance à conseiller aux plus jeunes de faire un travail plus visible.
Je m’y reconnais un peu aussi... haha
Est-ce que c’est propre au marché coréen seulement...
Je m’intéresse beaucoup à React Native, donc celui-ci m’intrigue aussi.
Le contenu ci-dessus est repris de la présentation officielle Lynx: Unlock Native for More.
J’ai aussi contribué à la partie gestion mémoire du noyau Linux, et je pense avoir une certaine compréhension du fonctionnement bas niveau. Mais quand je vois qu’au final je fais malgré moi un travail assez éloigné du développement, je me dis qu’il faut peut-être agir à l’inverse de cet article pour devenir un ingénieur qui réussit.
En rentrant au pays, je me suis rendu compte que le marché coréen est trop petit et la concurrence trop forte, donc il y a peu d’entreprises ou de postes où l’on peut se concentrer sur le développement. Et comme tout le monde se bat pour obtenir ces rares places, on a finalement l’impression qu’il faut se concentrer sur ce qui attire le plus l’attention pour pouvoir faire le développement qu’on veut vraiment faire.
« Nous n’avons pas besoin d’un élève A+ capable de répondre à toutes les questions
Ce que nous voulons, c’est un élève B capable de voir et de poser des questions sur ce que les autres ont manqué »
En voyant ça, j’ai tout de suite pensé que j’étais justement un élève B, mais que les grandes entreprises ne regardent et ne recrutent que des élèves A+.
Je pense que le MCP n’est pas une spécification de communication de données au point de se réduire à du JSON, et qu’il est inutilement complexe.
Il n’y a pas si longtemps, j’ai animé au bureau un séminaire dans le cadre d’une étude du langage Kotlin, et je me souviens que la réaction avait été bonne parce que j’avais choisi de l’expliquer en le comparant au langage C++, principalement utilisé dans l’équipe. En réalité, je n’utilise presque jamais le C++, et les membres de l’équipe découvraient Kotlin pour la première fois, mais j’ai eu l’impression que, à bien des égards, cela avait aidé tout le monde à progresser.
Il semble que le dernier point de la traduction du résumé des avis sur Hacker News, « il pourrait être erroné de supposer que la productivité du logiciel n’a pas été multipliée par 5 à 10 », soit une mauvaise traduction. À la lecture du texte original, un résumé plus raisonnable serait plutôt quelque chose comme : « affirmer que la productivité du logiciel a été multipliée par 5 à 10 repose sur des hypothèses erronées concernant le gain de productivité ».
Oui, je suis d’accord. Il faut aussi savoir se rendre visible, et ce serait bien que les personnes qui donnent se fassent souvent des shout-outs entre elles. La culture d’entreprise elle-même devrait l’encourager.
Le terminal, vraiment...
> La plupart des programmeurs ne savent pas comment utiliser efficacement les outils LLM, ou ne s’y intéressent pas.
Étonnamment, beaucoup de développeurs autour de moi ne s’intéressent pas vraiment à la technologie. Ils passent la majeure partie de leur temps à consommer mécaniquement des YouTube Shorts nouveaux ou répétitifs.
Je me demande si MCP peut être du JSON.
On dirait que le tweet n’existe plus, ou que l’original a été supprimé.
J’aimerais bien l’essayer, mais même si c’est en preview, c’est payant et il n’y a pas de période d’essai, snif.
En cherchant, on voit aussi des gens dire qu’ils ont dépensé 5 dollars pour seulement quelques requêtes, donc j’imagine que ça dépend aussi de la taille du code du projet.
Il y a beaucoup de points intéressants, tant du point de vue des RH que de la culture d’entreprise.
Comme je ne connaissais pas bien le sujet, j’ai regardé, et il semble que le backdoor reference check corresponde à une vérification de réputation non désignée. Je le laisse ici au cas où d’autres personnes comme moi se poseraient la question.