Cet argumentaire de « ne pas réinventer la roue » est pour moi un automatisme malvenu que les gens de conseil sortent à tout va pour se donner du crédit. Je pense au contraire que si tu es débutant tu as tout intérêt à réimplémenter des choses existantes ; c'est ce qui te fera passer du stade « connaître » au stade « comprendre ».
À titre d'exemple, j'ai appris à l'école ce qu'étaient des arbres binaires équilibrés mais ce n'est qu'en implémentant un AVL que j'ai compris comment ça fonctionnait. Pourtant mon implémentation n'était qu'une roue mal fichue, mais je l'ai utilisée, j'ai rencontré des problèmes qui m'ont amené à encore plus de réflexion, je l'ai confrontée à des outils plus mûrs pour en apprendre d'avantage.
J'ai aussi codé le chargement d'images bmp, tga, pcx, gif et autres. Cela n'a aucun intérêt dans un projet puisque de nombreuses bibliothèques le font déjà bien et que certains formats sont complètement obsolètes, et en plus je connaissais déjà tous ces formats. Et pourtant ça m'a fait me confronter au RLE, à LZW, à la question de la représentation des couleurs, aux formats palette, rgb16 et autres. À l'époque je confrontais mon code aux temps de chargement d'ACDSee, ce qui m'a amené à la question de l'optimisation. C'était aussi un bon exercice de suivi de specs puisque tous ces formats sont bien définis et que les documents techniques sont disponibles. Il y a en particulier plein de variantes de gif et j'avais dû rassembler de nombreux exemples pour valider l'implémentation.
Réinventer la roue c'est aussi apprendre à gérer un projet. Si tu te dis, par exemple, « je vais implémenter une messagerie instantanée » tu vas devoir poser un cadre. Est-ce que le client tourne dans un terminal, une app desktop, un navigateur ? Comment le serveur fonctionne-t-il ? Gères tu les sockets toi-même, utilises-tu des bibliothèques pour cela ? Est-ce que tout passe par le serveur ? Est-ce du pair à pair ? Comment gères-tu la sérialisation ? T'appuies-tu sur un protocole existant ?
Savoir poser des limites, sélectionner des fonctionnalités et cadrer le projet pour l'amener à terme, c'est aussi quelque chose qui se comprend en pratiquant.
Enfin même de manière professionnelle il m'est arrivé de réimplémenter des choses pour des raisons de coût : nous commencions avec l'outil d'un tiers puis nous le remplacions par quelque chose rendant le même service pour un coût moindre et des performances meilleures.
Moi je crois que les bons sportifs ne sont pas dans les gradins à manger des chips. Je crois que les bons musiciens jouent tous les jours, reprennent des morceaux existants qu'ils jouent du mieux qu'ils peuvent, avec des accords ratés et en passant à côté de subtilités. Ce n'est sans doute pas aussi bien que le morceau original mais ça peut quand même être une belle reprise, et surtout ça les rend meilleurs à ce qu'il font.
Alors si tu es débutant, et d'ailleurs ça marche aussi si tu es expérimenté, et que tu réponds à une offre de la boîte où je travaille, mon conseil est d'avoir :
un CV court qui va à l'essentiel : « j'ai fait ceci et cela, ici et là bas » ;
du code public et une explication du pourquoi, ce que ça tu as appris et comment tu t'y prendrais si tu devais le refaire ;
éventuellement des liens vers des articles plus ou moins techniques que tu as écris (un journal sur LinuxFr.org par exemple :)), que je puisse voir que tu peux faire preuve de réflexion, d'analyse, de critique, ou que tu peux expliquer quelque chose à un tiers. Pas forcément lié à l'informatique : une recette de cuisine, comment tu as perdu 10 kg, comment tu as construit un abri de jardin, ou ton ressenti sur la gestion d'une vieille colonie de vacances ; peu importe du moment que ça ressemble à de l'analyse, de la critique constructive, de la réflexion.
# À bas les roues en bois
Posté par Julien Jorge (site web personnel) . En réponse au journal Du chemin à emprunter pour les développeurs débutants vers un premier emploi.... Évalué à 10.
Cet argumentaire de « ne pas réinventer la roue » est pour moi un automatisme malvenu que les gens de conseil sortent à tout va pour se donner du crédit. Je pense au contraire que si tu es débutant tu as tout intérêt à réimplémenter des choses existantes ; c'est ce qui te fera passer du stade « connaître » au stade « comprendre ».
À titre d'exemple, j'ai appris à l'école ce qu'étaient des arbres binaires équilibrés mais ce n'est qu'en implémentant un AVL que j'ai compris comment ça fonctionnait. Pourtant mon implémentation n'était qu'une roue mal fichue, mais je l'ai utilisée, j'ai rencontré des problèmes qui m'ont amené à encore plus de réflexion, je l'ai confrontée à des outils plus mûrs pour en apprendre d'avantage.
J'ai aussi codé le chargement d'images bmp, tga, pcx, gif et autres. Cela n'a aucun intérêt dans un projet puisque de nombreuses bibliothèques le font déjà bien et que certains formats sont complètement obsolètes, et en plus je connaissais déjà tous ces formats. Et pourtant ça m'a fait me confronter au RLE, à LZW, à la question de la représentation des couleurs, aux formats palette, rgb16 et autres. À l'époque je confrontais mon code aux temps de chargement d'ACDSee, ce qui m'a amené à la question de l'optimisation. C'était aussi un bon exercice de suivi de specs puisque tous ces formats sont bien définis et que les documents techniques sont disponibles. Il y a en particulier plein de variantes de gif et j'avais dû rassembler de nombreux exemples pour valider l'implémentation.
Réinventer la roue c'est aussi apprendre à gérer un projet. Si tu te dis, par exemple, « je vais implémenter une messagerie instantanée » tu vas devoir poser un cadre. Est-ce que le client tourne dans un terminal, une app desktop, un navigateur ? Comment le serveur fonctionne-t-il ? Gères tu les sockets toi-même, utilises-tu des bibliothèques pour cela ? Est-ce que tout passe par le serveur ? Est-ce du pair à pair ? Comment gères-tu la sérialisation ? T'appuies-tu sur un protocole existant ?
Savoir poser des limites, sélectionner des fonctionnalités et cadrer le projet pour l'amener à terme, c'est aussi quelque chose qui se comprend en pratiquant.
Enfin même de manière professionnelle il m'est arrivé de réimplémenter des choses pour des raisons de coût : nous commencions avec l'outil d'un tiers puis nous le remplacions par quelque chose rendant le même service pour un coût moindre et des performances meilleures.
Moi je crois que les bons sportifs ne sont pas dans les gradins à manger des chips. Je crois que les bons musiciens jouent tous les jours, reprennent des morceaux existants qu'ils jouent du mieux qu'ils peuvent, avec des accords ratés et en passant à côté de subtilités. Ce n'est sans doute pas aussi bien que le morceau original mais ça peut quand même être une belle reprise, et surtout ça les rend meilleurs à ce qu'il font.
Alors si tu es débutant, et d'ailleurs ça marche aussi si tu es expérimenté, et que tu réponds à une offre de la boîte où je travaille, mon conseil est d'avoir :