Équilibre entre «le bon outil pour le travail» et la familiarité [fermé]

Ainsi, lors du choix de la langue à utiliser pour un projet, dans un monde idéal, la langue est choisie car c'est le bon outil pour le travail. Cependant, je préfère souvent utiliser une langue que je parle couramment plutôt que celle que je devrais apprendre ou dans laquelle je ne parle que. Bien entendu, la maîtrise de la langue implique également la connaissance des bibliothèques applicables dans la langue. Ce n'est pas parce que j'aime vraiment un langage assez polyvalent comme Java que je devrais toujours l'utiliser, mais en même temps cela ne signifie pas que je devrais sortir quelque chose comme Perl chaque fois qu'il y a du traitement de texte à faire. Comment trouver l'équilibre ici?

Wow, c'est une question TRÈS difficile à sortir du monde de la théorie et du monde de la production.

En théorie

Facile. Utilisez toujours le meilleur outil pour le travail et apprenez simplement ce dont vous avez besoin.

En pratique

Non seulement il y a la question de votre maîtrise, mais il y a une foule d'autres questions commerciales qui doivent être posées avant de pouvoir y répondre:

• Coût d'achat du "bon outillage"
• Coût du soutien - les gens doivent être formés
• Coût de la courbe d'apprentissage
• Coût d'intégration avec d'autres produits (maintenant et à l'avenir)
• ... etc

En dehors de la théorie, il existe de graves ramifications pour votre choix technologique.

Maintenant, je ne dis pas de ne pas choisir le bon outil - assurez-vous simplement que le bon outil sera en mesure de rentabiliser son implication en termes de coûts.

S'il s'agit d'un projet personnel - utilisez toujours l'outil "correct" - donc lorsque vous êtes confronté à cette décision dans le contexte commercial, vous pouvez effectuer un appel mieux informé.

Je pense que la familiarité n'est pas suffisamment valorisée. Votre familiarité influence très bien le bon outil. Vous devez utiliser l'outil pour terminer votre projet. De plus, l'utilisation de quelque chose que vous aimez peut sans aucun doute dépasser les lacunes de sa forme physique, car vous serez plus excité à l'idée de travailler et vous obtiendrez de meilleurs résultats.

http://headrush.typepad.com/creating_passionate_users/2006/08/when_the_best_t.html

Ce n'est pas vraiment résolu, sauf comme une question commerciale. Cependant, de nombreuses questions commerciales ne se posent que sur les chiffres à court terme, ce qui est une erreur avec des choses comme ça.

Mon approche générale:

1. Si c'est une chose petite ou à court terme, écrivez-la toujours dans les outils familiers.
2. Si c'est une grande chose à long terme, regardez le compromis coût-avantage de l'apprentissage d'un nouvel outil.
3. Si vous n'êtes pas sûr, traitez-le comme une chose à court terme jusqu'à ce que vous ayez la preuve que c'est une chose à long terme. Ensuite, revoyez la décision.

Trois choses à garder à l'esprit lorsque vous pensez aux coûts et aux avantages: Premièrement, les personnes pressées ont tendance à court-circuiter l'avenir. Deuxièmement, les coûts de maintenance représentent la part du lion des coûts de tout système performant. Troisièmement, les bons développeurs aiment apprendre des choses et garder leurs développeurs heureux est un bon investissement à long terme.

Grande question! Comme l'a dit whatsisname dans sa réponse, "la familiarité n'est pas suffisamment valorisée". Un outil différent, un cadre différent, un langage différent pourraient être bien meilleurs que ce que vous avez l'habitude d'utiliser, et vous seriez toujours beaucoup moins productif avec lui la première fois que vous apprendrez les cordes.

Je travaille depuis quelques années en tant que développeur ASP.NET dans des agences numériques où nous avons un mélange de gros projets, de petits projets, de projets serrés, de projets bien rembourrés, etc. Ce que nous essayons de faire, d'élargir nos compétences, est de rechercher des "cibles souples", des projets plus petits qui n'ont pas de délais douloureusement serrés et durs, et de les utiliser comme une opportunité d'utiliser de nouvelles technologies qui pourraient être supérieures. .NET 2.0, 3.5, 4.0, ASP.NET MVC, Linq to SQL, Entity Framework - tous, je les ai utilisés pour la première fois dans un tel projet.

Si vous pouvez saisir vos opportunités comme ça, alors j'espère que vous serez prêt avec une plus grande suite d'options pour choisir le bon outil sans souffrir d'un manque de familiarité. Tout comme dans l'exemple de Julio: ils ont trouvé une cible où ils pourraient ajouter Ruby à leur répertoire, et maintenant, ils peuvent choisir entre Java et Ruby.

Mais si le délai est court et solide et que le projet est important, je vous recommande de vous en tenir aux outils familiers. Quelque chose de différent pourrait être mieux adapté, mais dans des projets comme celui-ci, tout est question de risque .

Cela dépend de quelques éléments:

1. À quel point vous êtes doué pour apprendre de nouvelles langues ou de nouveaux outils.

Si vous étudiez rapidement, l'obstacle à l'apprentissage de nouvelles langues ou de nouveaux outils est plus faible. Cela vous donne la possibilité d'ajouter un autre outil à la boîte à outils.

2. Indépendamment de la langue / des outils, vous rendez votre environnement de travail.

Si votre flux de travail dépend fortement des outils, les obstacles à l'apprentissage de différentes langues sont plus élevés. Si vous êtes lié à un IDE particulier, changer de langue implique bien plus que simplement apprendre une langue, car l'édition de texte vous frustrera sûrement.

Quelqu'un qui utilise vim ou emacs n'a pas ce problème. Tout ce qu'ils ont à faire est d'apprendre la nouvelle langue.

3. Réalité commerciale

L'apprentissage de nouveaux outils / langages prend du temps. Ce temps a un coût. Mais ce coût a le potentiel d'être un investissement qui rapporte plus que la dépense initiale. De plus, une solution peu avantageuse prendra généralement plus de temps à mettre en œuvre et sera plus difficile à maintenir. Si c'est quelque chose de plus grand qu'un petit projet et que les outils de ma boîte à outils existante ne semblent pas convenir au problème, je rechercherai quels outils conviennent au problème. J'ai également investi dans un environnement adapté à une approche généraliste, en apprenant à utiliser vim comme éditeur choisi.

Autre chose - quelle est la distance la plus courte entre deux points? Si quelqu'un d'autre a écrit quelque chose qui fait presque ce que je veux faire, il est généralement plus rapide de le modifier en fonction de mes besoins.

S'il y a une nouvelle langue qui vous intéresse et que vous (et l'entreprise) pouvez vous le permettre, pourquoi ne pas vous donner quelques semaines à un mois pour l'explorer?

C'est ainsi que j'ai appris le rubis. Mon codeur partenaire avait 7 ans d'expérience avec Java. J'avais 11 ans d'expérience Java. Aucun de nous ne savait quoi que ce soit sur le rubis, seulement que nous voulions l'essayer.

Je l'ai convaincu, lui et le reste de l'entreprise, d'essayer le rubis pendant un mois (cela allait être un projet de 6 à 8 mois). Dans le pire des cas, nous recommencerions cette fois en utilisant Java.

Heureusement, après une semaine, nous étions accro, donc ça s'est bien passé. Peut-être pouvez-vous essayer quelque chose de similaire? Voyez si vous pouvez construire quelque chose à partir de zéro dans une autre langue, mais expliquez clairement à l'entreprise pourquoi vous le faites, et au moins aussi important, quel est le plan B en cas d'échec de l'expérience.

Il n'y a évidemment pas de réponse unique à cette question qui s'applique à toutes les situations. Mais voici un aspect qui, je pense, n'a pas encore été mentionné. Si vous êtes un développeur, vous devez également prendre en compte votre propre commercialisation. Si la langue X est choisie pour votre projet, à quoi cela ressemblera-t-il sur votre CV? Il peut être judicieux de choisir une langue que vous ne connaissez pas afin d'avoir une raison de l'apprendre, d'élargir vos horizons intellectuels et de rendre vos compétences plus attrayantes pour les futurs employeurs.

Je dirais que la familiarité avec une langue est également un aspect de «être un bon outil pour un emploi». Je ne peux pas imaginer une situation où c'est-à-dire Prolog serait un bon outil pour le travail pour moi étant donné ma totale ignorance de la langue.

Ma propre version consiste à «utiliser le bon outil à ma disposition» pour le travail. Être «disponible» signifie que je peux l'utiliser, pas seulement que je peux acheter / obtenir le compilateur et // ou le runtime.

Dans presque tous les scénarios réels, étant donné un problème, vous avez très peu de temps pour le résoudre. Je ne pense pas que vous puissiez vraiment apprendre une nouvelle langue en très peu de temps . Apprendre une langue signifie réellement lire des livres, parcourir le code des autres, comprendre comment cela fonctionne et la philosophie qui en découle. On pourrait simplement lire un tutoriel sur le Web (ce qui est parfaitement bon comme point de départ) et obtenir un piratage. Mais cela conduirait à un code terrible et vous feriez probablement mieux d'écrire un meilleur code dans une langue que vous connaissez en un temps peut-être beaucoup plus court.

Malgré les mérites du proverbe «le bon outil pour l'emploi», la plupart des langues populaires sont en fait à usage général. Ils peuvent avoir des forces dans certains domaines et ne pas être aussi bons que d'autres dans d'autres domaines, mais ils peuvent faire la plupart des travaux. Ne pas connaître une langue signifie que cet outil n'est pas à votre disposition.

Je ne dis pas simplement apprendre une (ou même deux ou trois) langues et les utiliser pour tous les projets et ne rien apprendre d'autre. Il est important d'apprendre d'autres langues, d'acquérir plus d'outils à ajouter à votre boîte à outils. Mais face à un problème, il vaut mieux s'en tenir aux outils que vous connaissez plutôt que d'ajouter à vos soucis en utilisant des technologies inconnues. Mais continuez à apprendre d'autres langues pour que la prochaine fois le choix soit plus facile.