Depuis quand on apprend des choses dans les formations d'IT ?

DEPUIS nullepart,  
Perso, c'est le genre de formation ou tu passes une semaine à faire des trucs, suivre un mec, à la fin de la semaine tu as des questions ou un exercice, mais au final tu vas oublier tout ça au bout de 2 semaines, parce que surtout tu n'en as pas besoin et tu n'en as rien à foutre.
Et tu vas payer ça 1000 balles minimum par tête.
 
Alors qu'un bouquin c'est 50 balles.

Un bouquin c'est le même concept tu vas le lire, pas appliquer et tu auras oublié aussi

J'suis dans une "formation" Rust à distance (qui en fait est une présentation). Le mec est perdu, il lit tout le temps ses notes. Trois fois sur quatre, le mec sait pas répondre à nos questions.
"Pourquoi on utilise pas const partout si let est par défaut immutable ?" - "je sais pas".
"Pour la diff entre String et str, me posez pas de questions svp je saurais pas vous répondre."
 
On verra si la suite empire ou pas.

le gars devrait faire le tutorial

C'est un concept de faire payer un training pour te faire suivre le truc gratos du site officiel

Rust c'est pas le truc le plus simple à donner comme formation, le compilateur te saute dessus au moindre truc, et pas mal de choses sont hyper subtiles si tu viens d'un autre langage.

Masklinn va te dire que si tu connaissais bien au moins un ML ou Haskell, et que t'étais familier avec les types linéaires, et les dingueries de C++, c'est facile en fait, bande de noobs.

Je sais pas qui a spiké ton repas ce midi, mais je pense pas avoir un jour dit que rust était un langage facile.

Pas con.

C'est un concept de faire payer un training pour te faire suivre le truc gratos du site officiel

Je sais pas qui a spiké ton repas ce midi, mais je pense pas avoir un jour dit que rust était un langage facile.

C'est toujours marrant de tomber sur un commentaire sur HN qui répond de manière bien détaillée à une affirmation incorrecte sur un point de Rust, puis voir que c'est toi.

 
je crois que c'était une blague. Ça m'a fait sourire parce que c'est quelque chose que tu aurais pu avoir dit.

Pour en revenir à l'agile vous faites vraiment vos estimations en points ?
 
C'est pas un peu bullshit ? Le peu de fois où je l'ai fait j'avais tendance à faire la conversion point/heure.

Pour en revenir à l'agile vous faites vraiment vos estimations en points ?

C'est pas un peu bullshit ? Le peu de fois où je l'ai fait j'avais tendance à faire la conversion point/heure.

Pour en revenir à l'agile vous faites vraiment vos estimations en points ?
 
C'est pas un peu bullshit ? Le peu de fois où je l'ai fait j'avais tendance à faire la conversion point/heure.

Rust c'est pas le truc le plus simple à donner comme formation, le compilateur te saute dessus au moindre truc, et pas mal de choses sont hyper subtiles si tu viens d'un autre langage.
 

 
     
naaaaaaaaan mais tu vois les points c'est un label, pour réduire l'affect et les effets d'ancrage liés à la notion de temps, et permettre d'inclure d'autres notions comme la complexité perçue, et puis...
 
non j'y arrive pas j'ai jamais vu d'implémentation de ce truc où on finisse pas par avoir un mapping fixe entre point et charge...ne serait-ce que parce que les Engineering managers finissaient toujours pas avoir besoin d'un truc pour savoir si Bob et Josianne vont etre sous l'eau ou vont rien avoir à foutre au prochain sprint...et que si toute la charge de Bob et Josianne est exprimée en point, à un moment c'est super tentant de faire une règle à la grosse genre 2*5*8 / sum(points) = valeur du point en heure

C'est de la merde de faire en point.
Désolé koskoz

C'est de la merde de faire en point.
Désolé koskoz

Reddit est down je vais être obligé de jouer à Bioshock

Muchacho  

 
     
naaaaaaaaan mais tu vois les points c'est un label, pour réduire l'affect et les effets d'ancrage liés à la notion de temps, et permettre d'inclure d'autres notions comme la complexité perçue, et puis...
 
non j'y arrive pas j'ai jamais vu d'implémentation de ce truc où on finisse pas par avoir un mapping fixe entre point et charge...ne serait-ce que parce que les Engineering managers finissaient toujours pas avoir besoin d'un truc pour savoir si Bob et Josianne vont etre sous l'eau ou vont rien avoir à foutre au prochain sprint...et que si toute la charge de Bob et Josianne est exprimée en point, à un moment c'est super tentant de faire une règle à la grosse genre 2*5*8 / sum(points) = valeur du point en heure

On va se calmer, ça fonctionnait très bien ce matin, c'est bien trop récent pour Much

 
Je parlais de Bioshock. Il n'a que 15 ans, c'est vrai que c'est un peu récent.

C'est de la merde de faire en point.
Désolé koskoz

 
     
naaaaaaaaan mais tu vois les points c'est un label, pour réduire l'affect et les effets d'ancrage liés à la notion de temps, et permettre d'inclure d'autres notions comme la complexité perçue, et puis...
 
non j'y arrive pas j'ai jamais vu d'implémentation de ce truc où on finisse pas par avoir un mapping fixe entre point et charge...ne serait-ce que parce que les Engineering managers finissaient toujours pas avoir besoin d'un truc pour savoir si Bob et Josianne vont etre sous l'eau ou vont rien avoir à foutre au prochain sprint...et que si toute la charge de Bob et Josianne est exprimée en point, à un moment c'est super tentant de faire une règle à la grosse genre 2*5*8 / sum(points) = valeur du point en heure

DEPUIS nullepart,  
Perso, c'est le genre de formation ou tu passes une semaine à faire des trucs, suivre un mec, à la fin de la semaine tu as des questions ou un exercice, mais au final tu vas oublier tout ça au bout de 2 semaines, parce que surtout tu n'en as pas besoin et tu n'en as rien à foutre.
Et tu vas payer ça 1000 balles minimum par tête.
 
Alors qu'un bouquin c'est 50 balles.

 
 
Quand c'est bien fait, c'est comme une video d'une 1h sur youtube, sauf que là tu peux direct poser tes questions et avoir les réponses. Voire même débuter un ptit projet. Ca permet juste de découvrir beaucoup plus vite.    
 
Et dans le cas de Rust, voir des éléments importants en prio, plutôt que d'être noyé dans le cookbook.

C'est moins cher.
 
Le combo : Video youtube + chatGPT pour poser des questions + livre pour approfondir le langage ça peut etre pas mal.

Rust c'est pas le truc le plus simple à donner comme formation, le compilateur te saute dessus au moindre truc, et pas mal de choses sont hyper subtiles si tu viens d'un autre langage.
 
Pour String vs str, le gars devrait faire le tutorial, c'est expliqué dedans :  
https://doc.rust-lang.org/book/ch04 [...] rship.html
https://doc.rust-lang.org/book/ch04-03-slices.html
 

T'es lourd avec ChatGPT à force.  

 
Désolé si ça te fait chier, mais j'ai juste énuméré un outil parmi d'autres, je n'ai jamais dit que c'est la source ultime hein, mais derrière si tu as des questions spécifiques, tu peux toujours poser ta questions en mettant évidemment le contexte et aller chercher plus d'infos sur le net.
 
J'ai aussi oublier l'essentiel, la documentation du langage ou de l'outil qu'on utilise, elle est souvent assez bien fournie pour ne pas aller voir ailleurs.

 
ça ne me fait pas chier. J'ai même fait intégrer l'API d'OpenAI dans l'une de nos solution pour un truc spécifique. C'est juste que tu n'as que ChatGPT à la bouche (enfin au bout des doigts ). On a compris que ChatGPT c'est super...

En tant qu'IA je n'ai pas non plus la même impression.

Pour en revenir à l'agile vous faites vraiment vos estimations en points ?
C'est pas un peu bullshit ? Le peu de fois où je l'ai fait j'avais tendance à faire la conversion point/heure.

Pas vu d'estimation (que ce soit en points abstrait ou temps) faite encore depuis 2 mois (bon je suppose que c'est notre manager qui les fait ?)
 
Mais sinon avant, j'ai essayé les points "abstraits", dans 2 boites différentes, avec 3 équipes différentes. Franchement, c'est peut être nous qui nous nous y prenions mal, bien qu'on ait essayé de faire ça bien: avec des "taches étalons", pour donner des exemples de tâches et les points associés... Bin rien à faire, les estimations étaient pas spécialement plus qualitatives que quand on était en temps.
Et en plus je trouve que c'est limite plus compliqué à posteriori: une fois que tu as fini ta tache, si tu context-switch pas trop, c'est relativement facile de savoir si t'es sur une tache depuis 2h, 2 ou 3 jours ou 2 semaines: le temps tu le "vois passer". Donc quand t'es en temps, comparer la "prédiction" avec le temps réellement passé, c'est assez facile. Par contre, c'est plus compliqué je trouve de dire "ah bin non, en fait c'était pas une tache à 3 points, mais une à 7". Disons que ça fait a nouveau plus appel à l'estimation de la personne qu'un truc plus "mesurable".  
 
Et pareil, comme le dit Jubi, au final les N+X ce qu'ils veulent c'est savoir quand (environ) c'est fini, du coup in fine à la fin tu te retrouves toujours à faire une conversion points abstraits => temps.
 
Le truc le plus important pour moi si vous estimez en temps en fait, c'est de faire comprendre que c'est pas parce qu'une tâche estimée à 5 jours qui commence le lundi matin à 9h sera fini le vendredi soir. Et j'ai l'impression que y a pas mal d'équipes ou la tentation de passer en point abstrait est parce que les managers ou les N+X confondent estimation et deadline... Mais au final le passage en point règle pas la question de fond (et souvent ça ne fait que gagner un peu de temps avant que les échelons supérieurs reviennent à la charge pour savoir quand ça sort)

Ça doit faire 10 ans que je fais du scrum en jours/homme mais on applique un coefficient de "focalisation" aux jours de présence de l'équipe.  
En général on est à 60% de coefficient de focalisation (pour des équipes de dev qui font aussi de la maintenance et du support).

Pas vu d'estimation (que ce soit en points abstrait ou temps) faite encore depuis 2 mois (bon je suppose que c'est notre manager qui les fait ?)
 
Mais sinon avant, j'ai essayé les points "abstraits", dans 2 boites différentes, avec 3 équipes différentes. Franchement, c'est peut être nous qui nous nous y prenions mal, bien qu'on ait essayé de faire ça bien: avec des "taches étalons", pour donner des exemples de tâches et les points associés... Bin rien à faire, les estimations étaient pas spécialement plus qualitatives que quand on était en temps.
Et en plus je trouve que c'est limite plus compliqué à posteriori: une fois que tu as fini ta tache, si tu context-switch pas trop, c'est relativement facile de savoir si t'es sur une tache depuis 2h, 2 ou 3 jours ou 2 semaines: le temps tu le "vois passer". Donc quand t'es en temps, comparer la "prédiction" avec le temps réellement passé, c'est assez facile. Par contre, c'est plus compliqué je trouve de dire "ah bin non, en fait c'était pas une tache à 3 points, mais une à 7". Disons que ça fait a nouveau plus appel à l'estimation de la personne qu'un truc plus "mesurable".  
 
Et pareil, comme le dit Jubi, au final les N+X ce qu'ils veulent c'est savoir quand (environ) c'est fini, du coup in fine à la fin tu te retrouves toujours à faire une conversion points abstraits => temps.
 
Le truc le plus important pour moi si vous estimez en temps en fait, c'est de faire comprendre que c'est pas parce qu'une tâche estimée à 5 jours qui commence le lundi matin à 9h sera fini le vendredi soir. Et j'ai l'impression que y a pas mal d'équipes ou la tentation de passer en point abstrait est parce que les managers ou les N+X confondent estimation et deadline... Mais au final le passage en point règle pas la question de fond (et souvent ça ne fait que gagner un peu de temps avant que les échelons supérieurs reviennent à la charge pour savoir quand ça sort)

This.
Beaucoup de personnes confondent charge et délai.