Nous avons probablement tous rencontré quelqu'un comme ça, ce développeur qui sait juste que sa langue est la seule vraie langue et ne se taira pas à ce sujet. Comment gérez-vous comme quelqu'un comme ça? Je ne veux offenser personne (surtout que le fanboy de mon lieu de travail est le développeur principal). Mais je veux pouvoir utiliser mon propre choix de langage de script lorsque je dois écrire un script jetable qui ne parvient jamais au référentiel et que personne d'autre n'a besoin de savoir qu'il existait.
Réflexions auxquelles j'ai dû faire face:
- Riez-le - "Haha ouais peut-être que la langue X est un peu plus facile, je suppose que je suis masochiste!"
- Allez-y - je préférerais vraiment éviter cela car je ne peux pas me permettre la baisse de productivité associée au choix d'une nouvelle langue.
- Masquer ma langue - Devenez un programmeur de garde-robe et cachez mon moniteur chaque fois que je crée un script ou automatise quelque chose.
Que suggéreriez-vous pour cette situation?
programming-languages
teamwork
language-choice
Daniel Gratzer
la source
la source
Réponses:
Peu de choses sortent de la question.
Je comprends un peu la partie fan-boy, parce que d'un côté, je me comporte parfois comme un fan-boy, tout en protégeant mes quelques langues de choix. Et j'ai également eu affaire à d'autres fan-boys qui essaient d'apporter de nouvelles choses.
Ma vision de cette situation est la suivante:
C'est parce que personne ne sait écrire des logiciels sûrs et rapides dans une langue inconnue, et il a tout ce que les développeurs doivent apprendre. Le script stupide devra être soutenu pendant 20 ans ou réécrit. En 20 ans, au moins 50 développeurs changent dans une boutique moyenne. Si chacun écrit quelques scripts fantaisie dans une nouvelle langue, vous avez besoin de 50 runtimes de langue, 50 expertises différentes sur l'équipe, et la base de code a du code bogué dans 50 langues. Et certaines langues ne sont plus prises en charge sous Windows ou Linux. Et a besoin de ce serveur personnalisé inédit de 10 ans, sans pièces de rechange disponibles, 24/7.
De plus, personne ne veut vraiment prendre en charge les langages morts comme VB, Silverlight, D, etc., alors que la base de code survivra probablement au langage lui-même.
la source
Décide-t-il de ce que vous utilisez en fonction de la politique de l'entreprise? Appelez-lui votre cas; s'il décide toujours contre, tais-toi et fais ton travail avec les outils que ton patron te dit d'utiliser.
Vous y travaillez , vous n'y jouez pas. En fin de compte, c'est hors de vos mains.
Même s'il n'est pas votre patron, je considérerais tous les angles ici. Aimeriez-vous qu'il connaissait Fortran et qu'un jour vous ayez hérité de tout son code. Il faudrait apprendre une toute nouvelle langue à partir de zéro à la volée , c'est terriblement stressant. Imaginez maintenant son côté, vous pourriez écrire vos scripts en utilisant Cobol et il ne connaît peut-être pas Cobol.
Utilisez quelque chose que la majorité de votre équipe sait.
la source
Ceci est la seule réponse raisonnable. Vous avez une grande opportunité ici.
Utilisez les commentaires du programmeur principal pour encourager votre entreprise à payer du temps et / ou un cours et / ou une certification pour apprendre la nouvelle langue. Pire scénario: la certification et la langue amélioreront votre CV, vous obtiendrez peut-être une bonne recommandation pour être un joueur d'équipe et vous pourrez rire jusqu'à un meilleur emploi ailleurs.
J'ai acquis de précieuses informations sur la programmation dans chaque langue que j'ai apprise. Même le moins pratique de la langue ( toux XSLT toux ) avait sa tache douce et était plein à craquer de possibilités d'apprentissage intéressantes (et payé mes factures depuis plusieurs années). L'apprentissage constant est l'un des grands avantages d'être programmeur.
Tous les projets sympas utilisent probablement la langue préférée du développeur senior. Connaître cette langue vous place dans le vivier de talents qui peuvent travailler sur ces projets.
Quelqu'un vous paie probablement pour effectuer certains travaux d'une certaine manière. Toute autre réponse est probablement une insubordination et risque de se terminer mal.
Le développeur / architecte principal choisit normalement la langue principale utilisée dans un magasin et s'assure que tout le monde utilise cette langue. De cette façon, une entreprise construit une base de connaissances dans certaines technologies afin qu'un employé (vous) puisse prendre des vacances et que quelqu'un d'autre puisse récupérer votre code et le corriger pendant votre absence. L'entreprise peut également attirer des talents de formation pertinents et le service des ressources humaines saura quels mots à la mode rechercher dans les curriculum vitae.
En apprenant sa langue et en l'utilisant pour son travail, vous accumulez le capital politique dont vous avez besoin pour défendre efficacement votre langue préférée. De nombreuses entreprises ont un langage d'infrastructure officiel et un langage de script officiel pour les rapports. Préparez une liste des avantages et des inconvénients indiquant où sa langue excelle et où la vôtre le fait, ainsi que les points faibles de chacun. Vous devez conserver cette liste dans le contexte d'une application spécifique, comme les rapports que vous rédigez. Prévoyez un moment avec lui pour lui montrer la liste en privé et avec respect et en discuter avec lui. Notez ses objections, recherchez-les après la réunion et, si vous avez de bons contre-arguments, planifiez une réunion de suivi.
Bonne chance!
la source
Montrez que dans un contexte spécifique, une autre langue est un choix plus pragmatique.
Si la personne est passionnée par le C ++ et que vous travaillez sur un projet d'application Web, ce ne serait pas trop difficile. De la même manière, certains contextes sont très enclins à la programmation fonctionnelle et utiliser un langage non fonctionnel ne serait pas très sage.
Remarques:
Évitez les situations où votre langue et celle que vous préférez sont très similaires.
Par exemple, j'imagine difficilement un contexte où Java serait "meilleur" que C #, ou C #, "meilleur" que Java.
N'oubliez pas que le choix d'une langue est très souvent subjectif et s'explique davantage par l'expérience antérieure d'un développeur que par certains éléments fondés sur des preuves.
Par exemple, si on me demande de faire une application relative au secteur financier, j'utiliserais toujours C # plutôt que Haskell, même si je trouve Haskell plus approprié et vraiment excitant. La raison de ce choix est que j'ai des années d'expérience avec C #, mais en ce qui concerne Haskell, je n'ai lu que quelques tutoriels et je ne l'ai jamais utilisé professionnellement.
la source
La réponse est 2) Allez-y.
C'est gagnant-gagnant-gagnant-gagnant. Prendre plaisir!
la source
La réponse est que vous ne vous en occupez pas. Discuter avec eux entraîne simplement l'argumenteur à son niveau (où il vous bat avec l'expérience) et n'est finalement pas constructif car ils sont étroits d'esprit.
Ignorez tous les arguments qu'ils donnent pour ou contre leur langue et décidez-vous. Utilisez les techniques habituelles comme éviter le contact visuel, répondre de façon monosylabique et passer à un nouveau sujet lorsque le silence le garantit. Formez-les plutôt à ennuyer la personne à côté de vous.
Le défi ici est que le fan boy associe la langue à son identité et toute négativité associée à cette langue est personnelle. N'attaquez pas et ne vous défendez pas. Ignorez simplement.
la source
Très peu de choses au travail sont vraiment des scripts jetables. Je finis par mettre beaucoup de ces choses sur le wiki ou dans le référentiel de toute façon au cas où cela serait à nouveau nécessaire.
Même les choses que je pense sont inférieures au niveau de partage, mes coéquipiers se sentent souvent différemment. Par exemple, j'ai un alias rgrep dans mon .profile. C'est juste une instruction find avec un paramètre car je n'ai pas accès à un vrai rgrep sur ce serveur. Un coéquipier a eu du vent et l'a voulu sur le wiki .. Oui, la déclaration d'une ligne. De toute évidence, nous n'avons pas eu de débat sur le langage d'implémentation - il devait s'agir d'UNIX. Mais cela met en évidence la nécessité de faire des choses que les autres membres de l'équipe peuvent comprendre.
Un autre tour est qu'il est possible que le développeur senior ait une raison que vous ne connaissez pas pour utiliser ce langage. Avez-vous demandé?
Essayez peut-être de faire une fois le même script dans les deux langues pour montrer pourquoi le vôtre est meilleur.
la source
Vous devriez essayer la buée . Cela signifie être d'accord avec tout ce que le fanboy dit (en tout ou en partie), mais faites votre propre chose, sauf instruction explicite de faire autrement.
la source
Les options passives-agressives 1,3 conduisent à plus de détresse émotionnelle, alors donnez-moi un 2) prenez-le sur le menton.
Quelques conseils généraux pour la route: 4) Si vous n'écoutez pas plus intelligemment votre aîné, faites votre propre étude en conception de langage / compilateur. Choisissez une langue et découvrez les idées qui y sont entrées. Quel est le compromis entre les fonctionnalités, les performances et la puissance expressive. Quelles autres options sont là. Cela seul vous accordera des super-pouvoirs de programmation inhumains. Apprendre le NBL même, ça va être énorme.
S'affirmer en poussant des opinions sur les autres nuit à la productivité et à la communication. Les gens peuvent penser que renoncer à l'envie émotionnelle est utile, mais c'est un simple pansement sur leur insécurité.
Être humble et gentil avec des conseils et vous améliorer vous fera des merveilles pour exprimer vos sentiments intestinaux au niveau technique. Vous vous sentirez mieux et verrez les choses pour ce qu'elles sont, car vous pourrez raisonner. Difficile de se fâcher quand on extériorise la critique à un contexte technique.
la source