J'apprend régulièrement des nouveaux langages justement parce que c'est plus adapté aux problèmes rencontrés. Genre ces derniers mois du clojure parce que la gestion des données correspondait très bien au métier, et du Ada parce que c'est quand même vachement bien pour certains problèmes.
À toucher à trop de choses on finit par réapprendre des choses peu utiles et à ne rien approfondir suffisamment pour maîtriser dans le vrai sens du terme. Celui qui se fait avec plusieurs années d'expérience et des codes assez différents. Toucher à tout c'est sympas et très bien, mais il y a aussi de bonnes raisons pour utiliser un langage que l'on maîtrise : la rapidité à mettre en place le code (on parle ici d'un projet qui n'a pas un mois), la qualité du code (on évite des bugs), on se concentre sur le métier,...
C'est assez fou que moi j'ai à dire ça, vu que je suis plutôt orienté technique, mais il y a un moment où il faut arrêter la branlette intellectuelle sur la technique pour répondre à un besoin. Lui il a réussi à répondre à son propre besoin en moins de 4 semaines sur son temps libre, c'est plutôt cool je trouve.
Encore une fois ce logiciel n'a pas d'enjeux technique (il ne traite pas de gros volumes de données, ne s'appuie pas sur des algorithmes incroyables, n'a pas à s’exécuter dans un contexte embarqué ou cloud, etc). Donc venir expliquer que ces choix sont aussi mauvais que tu le dis est assez ridicule.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: scrum board.
Posté par barmic . En réponse à la dépêche Kanboard, un logiciel libre pour gérer ses projets avec la méthode Kanban. Évalué à 8.
À toucher à trop de choses on finit par réapprendre des choses peu utiles et à ne rien approfondir suffisamment pour maîtriser dans le vrai sens du terme. Celui qui se fait avec plusieurs années d'expérience et des codes assez différents. Toucher à tout c'est sympas et très bien, mais il y a aussi de bonnes raisons pour utiliser un langage que l'on maîtrise : la rapidité à mettre en place le code (on parle ici d'un projet qui n'a pas un mois), la qualité du code (on évite des bugs), on se concentre sur le métier,...
C'est assez fou que moi j'ai à dire ça, vu que je suis plutôt orienté technique, mais il y a un moment où il faut arrêter la branlette intellectuelle sur la technique pour répondre à un besoin. Lui il a réussi à répondre à son propre besoin en moins de 4 semaines sur son temps libre, c'est plutôt cool je trouve.
Encore une fois ce logiciel n'a pas d'enjeux technique (il ne traite pas de gros volumes de données, ne s'appuie pas sur des algorithmes incroyables, n'a pas à s’exécuter dans un contexte embarqué ou cloud, etc). Donc venir expliquer que ces choix sont aussi mauvais que tu le dis est assez ridicule.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)