Lidando com Fanboys [fechado]

Todos nós provavelmente já conhecemos alguém assim, aquele desenvolvedor que apenas sabe que seu idioma é o único idioma verdadeiro e não cala a boca. Como você lida com alguém assim? Não quero ofender ninguém (especialmente porque o fanboy no meu local de trabalho é o desenvolvedor sênior). Mas eu quero poder usar minha própria escolha de linguagem de script quando precisar escrever um script descartável que nunca chegue ao repositório e ninguém mais precise saber que existia.

Pensamentos que eu tive que lidar com isso:

1. Ria - "Haha, sim, talvez a linguagem X seja um pouco mais fácil, eu acho que sou masoquista!"
2. Vá em frente - eu realmente preferiria evitar isso, pois não posso permitir a queda de produtividade associada à escolha de um novo idioma.
3. Ocultar meu idioma - Torne-se um programador de armário e oculte meu monitor sempre que eu estiver criando scripts ou automatizando algo.

O que você sugeriria para esta situação?

Poucas coisas estão pulando fora de questão.

• É realmente um script descartável? Se for, é estranho que esteja sendo discutido.
• Tem certeza de que o script descartável permanecerá como está? Um monte de coisas de produção tem sido um script descartável em algum momento.
• Você vai reescrever o script se ele for promovido e precisar de integração no sistema?
• A escolha da língua é puramente sintática ou é uma língua de outra esfera?

Eu meio que entendo a parte de fã-boy, porque de um lado, eu estou me comportando como um fã de fã algumas vezes, enquanto protejo meus poucos idiomas de escolha. E também lidei com outros fan-boys que tentam trazer novidades.

Minha opinião sobre esta situação é assim:

• Se for um novo idioma, ele pertence a uma lixeira.
• Se for uma linguagem comprovada na indústria, poderá ser usada se for especializada para a tarefa.
• Se é um idioma muito impopular, ele pertence a uma lixeira, mesmo que seja super legal e super rápido.

É porque ninguém sabe escrever software seguro e rápido em um idioma desconhecido, e ele tem todas as dicas que os desenvolvedores precisam aprender. O script estúpido terá que ser suportado por mais de 20 anos ou reescrito. Durante 20 anos, pelo menos 50 desenvolvedores mudam em uma loja média. Se cada um escreve poucos scripts sofisticados em um novo idioma, você precisa de 50 tempos de execução de idiomas, 50 experiências diferentes na equipe e a base de código possui código de buggy em 50 idiomas. E alguns dos idiomas não são mais suportados no Windows ou Linux. E precisa desse servidor personalizado de 10 anos, sem patches, sem peças de reposição disponíveis, 24/7.

Além disso, ninguém quer realmente suportar idiomas mortos, como VB, Silverlight, D, etc., quando a base de código provavelmente sobreviverá ao próprio idioma.

Ele decide o que você usa com base na política da empresa? Apelar seu caso para ele; se ele ainda decidir contra, cale a boca e faça seu trabalho com as ferramentas que seu chefe diz que você deve usar.

Você trabalha lá, não brinca lá. Em última análise, está fora de suas mãos.

Mesmo que ele não seja seu chefe, eu consideraria todos os ângulos aqui. Você gostaria que ele conhecesse Fortran e um dia você herdasse todo o código dele. Você precisaria aprender um novo idioma em tempo real , o que é terrivelmente estressante. Agora imagine o lado dele, você pode escrever seus scripts usando Cobol e ele pode não conhecer Cobol.

Use algo que a maioria da sua equipe saiba.

"2. Vá em frente"

Esta é a única resposta razoável. Você tem uma grande oportunidade aqui.

• Use os comentários do programador sênior para incentivar sua empresa a pagar por tempo e / ou um curso e / ou certificação para aprender o novo idioma. No pior cenário: a certificação e o idioma melhoram o seu currículo, você pode receber uma boa recomendação para fazer parte de uma equipe e pode rir até conseguir um emprego melhor em outro lugar.

• Eu obtive informações valiosas sobre programação de todas as linguagens que aprendi. Até a linguagem menos prática ( tosse XSLT tosse ) teve seu ponto ideal e estava repleta de oportunidades interessantes de aprendizado (e paguei minhas contas por vários anos). O aprendizado constante é um dos grandes benefícios de ser um programador.

• Todos os projetos interessantes provavelmente usam o idioma favorito do desenvolvedor sênior. Conhecer esse idioma coloca você no grupo de talentos que podem trabalhar nesses projetos.

• Presumivelmente, alguém está pagando para você fazer certo trabalho de uma certa maneira. Qualquer outra resposta provavelmente é insubordinação e provavelmente terminará mal.

O desenvolvedor / arquiteto sênior normalmente escolhe o idioma principal usado em uma loja e garante que todos usem esse idioma. Dessa forma, uma empresa constrói uma base de conhecimento em determinadas tecnologias para que um funcionário (você) tire férias e alguém possa pegar seu código e corrigi-lo enquanto você estiver fora. Além disso, a empresa pode trazer talentos de treinamento relevantes e o departamento de RH saberá quais palavras de ordem procurar nos currículos.

Ao aprender o idioma dele e usá-lo para o trabalho, você acumula o capital político necessário para defender efetivamente seu idioma favorito. Muitas empresas possuem um idioma oficial de infraestrutura e um idioma oficial de script para relatórios. Prepare uma lista de prós e contras mostrando onde o idioma dele se destaca e onde o seu se destaca, e também onde cada um fica aquém. Você precisa manter essa lista no contexto de um aplicativo específico, como os relatórios que está escrevendo. Planeje um tempo com ele para mostrar-lhe a lista de maneira particular e respeitosa e discuti-la. Anote suas objeções, pesquise-as após a reunião e, se tiver bons contra-argumentos, planeje uma reunião de acompanhamento.

Boa sorte!

Mostre que em um contexto específico, outro idioma é uma escolha mais pragmática.

Se a pessoa é apaixonada por C ++ e você está trabalhando em um projeto de aplicativo da Web, não seria muito difícil. Da mesma forma, alguns contextos são muito inclinados à programação funcional e o uso de uma linguagem não-funcional não seria muito sábio.

Notas:

• Evite situações em que o seu idioma e o idioma preferido dele sejam muito semelhantes.

  Por exemplo, eu dificilmente imaginaria um contexto em que Java seria "melhor" que C # ou C #, "melhor" que Java.

• Lembre-se de que a escolha de um idioma é muitas vezes subjetiva e é explicada mais pela experiência anterior de um desenvolvedor do que por alguns elementos baseados em evidências.

  Por exemplo, se me pedissem para fazer um aplicativo em relação ao setor financeiro, ainda usaria o C # em vez do Haskell, mesmo que eu ache o Haskell mais apropriado e realmente emocionante. O motivo dessa escolha é que tenho anos de experiência com C #, mas quando se trata de Haskell, li apenas alguns tutoriais e nunca o usei profissionalmente.

A resposta é 2) Vá em frente.

1. A única maneira de calar a boca do fanboy é tornar-se fluente (até certo ponto) em seu idioma preferido.
2. A perda de produtividade não é um problema. Você está fazendo conforme solicitado pelo seu senior, portanto, as mudanças de produtividade devem ser acomodadas pelo projeto.
3. Aprender um novo idioma fará seu cérebro funcionar melhor.
4. Aprender a ser aberto sobre o aprendizado de novos idiomas fará com que você seja ainda mais bom.

É ganha-ganha-ganha-ganha. Desfrutar!

A resposta é que você não lida com isso. Discutir com eles apenas arrasta o argumentador até o nível deles (onde eles batem em você com a experiência) e, em última análise, não é construtivo, porque eles têm uma mente fechada.

Ignore quaisquer argumentos que eles apresentem a favor ou contra o idioma deles e decida-se. Use as técnicas usuais, como evitar o contato visual, responder monossilabicamente e passar para um novo assunto quando o silêncio garantir. Treine-os para irritar a pessoa ao seu lado.

O desafio aqui é que o fã-boy associe o idioma à sua identidade e qualquer negatividade associada a esse idioma é pessoal. Não ataque ou defenda. Só ignore.

Muito poucas coisas no trabalho são realmente scripts descartáveis. Acabo colocando muitas dessas coisas no wiki ou no repositório de qualquer maneira, caso seja necessário novamente.

Mesmo as coisas que acho que estão abaixo do nível de compartilhamento, meus colegas de equipe geralmente se sentem diferentes. Por exemplo, eu tenho um alias rgrep no meu perfil. É apenas uma instrução find com um parâmetro, já que não tenho acesso ao rgrep real nesse servidor. Um companheiro de equipe ficou sabendo e o queria no wiki. Sim, a declaração de uma linha. Obviamente, não tivemos um debate sobre a linguagem de implementação - tinha que ser o UNIX. Mas destaca a necessidade de fazer coisas que outras pessoas da equipe possam entender.

Outra mudança é que é possível que o desenvolvedor sênior tenha um motivo que você não conhece para usar esse idioma. Você já perguntou?

Talvez tente fazer o mesmo script nos dois idiomas uma vez para mostrar por que o seu é melhor.

Você deve tentar embaçar . Isso significa concordar com tudo o que o fanboy diz (em parte ou no todo), mas faça o que quiser, a menos que seja explicitamente instruído a fazer o contrário.

As opções passivo-agressivas 1,3 levam a mais sofrimento emocional, então dê-me um 2) leve-o ao queixo.

Alguns conselhos gerais para a estrada: 4) Se você não ouvir de maneira mais inteligente o seu aluno mais velho, faça seu próprio estudo em design de linguagem / compilador. Escolha um idioma e saiba quais pensamentos entraram nele. Qual é a troca entre recursos, desempenho e poder expressivo. Que outras opções existem? Isso por si só concederá superpoderes de programação desumanos. Aprenda NBL mesmo, vai ser enorme.

Afirmar a si mesmo empurrando opiniões sobre os outros inibe a produtividade e a comunicação. As pessoas podem pensar que desistir do desejo emocional é útil, mas é um mero auxílio à sua insegurança.

Ser humilde e gentil com conselhos e melhorar a si mesmo farão maravilhas para expressar seus sentimentos em um nível técnico. Você se sentirá melhor e verá as coisas como elas são, porque poderá raciocinar. É difícil ficar bravo quando você externaliza críticas para um contexto técnico.