« ABC: Always Be Coding » est à rapprocher d'un autre article sur le même sujet, mais qui donne des conseils à ceux qui pose des questions.
L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
Mais quel informaticien écrit en moyenne par mois, de tel algo ? Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.
Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.
# quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 10. Dernière modification le 17 juillet 2013 à 10:21.
« ABC: Always Be Coding » est à rapprocher d'un autre article sur le même sujet, mais qui donne des conseils à ceux qui pose des questions.
L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
Mais quel informaticien écrit en moyenne par mois, de tel algo ? Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.
Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.
"La première sécurité est la liberté"