Quanta liberdade um programador deve ter na escolha de uma linguagem e estrutura?

Comecei a trabalhar em uma empresa voltada principalmente para C #. Temos algumas pessoas que gostam de Java e JRuby, mas a maioria dos programadores aqui gosta de C #. Fui contratado porque tenho muita experiência na criação de aplicativos Web e porque me inclino para tecnologias mais recentes, como JRuby on Rails ou nodejs.

Recentemente, iniciei um projeto de construção de um aplicativo Web com foco em realizar várias coisas em um curto espaço de tempo. O líder do software determinou que eu use o mvc4 em vez dos trilhos. Isso pode ser bom, exceto que eu não conheço mvc4, não conheço C # e sou o único responsável por criar o servidor de aplicativos da web e a interface do usuário front-end.

Não faria sentido usar uma estrutura que eu já conheço extremamente bem (Rails) em vez de usar o mvc4? O raciocínio por trás da decisão foi que o líder técnico não conhece o Jruby / rails e não há como reutilizar o código.

Contra-argumentos:

• Ele não estará contribuindo para o código e, francamente, não é necessário
  neste projeto. Então, realmente não importa se ele conhece JRuby / rails ou não.

• Na verdade, podemos reutilizar o código, pois temos muitos aplicativos java dos quais o JRuby pode obter o código e vice-versa. De fato, ele dedicou alguns recursos para converter uma biblioteca Java em C #, em vez de apenas executar a biblioteca Java no aplicativo JRuby on Rails. Tudo porque ele não gosta de Java ou JRuby

Eu criei muitos aplicativos da Web, mas usar algo desconhecido está causando alguma repercussão e não consigo criar um aplicativo incrível em tão pouco tempo quanto estou acostumado. Isso seria bom; aprender novas tecnologias é importante neste campo. O problema é que, para este projeto, precisamos fazer muito rápido.

Em que momento um desenvolvedor deve poder escolher suas ferramentas? Isso depende da empresa? Minha empresa é péssima ou isso é considerado normal? Existem pastos mais verdes? Estou vendo isso da maneira errada?

Eu diria que você precisa conversar com o líder da equipe e dizer algo como:

Eu sei que vocês são uma loja .NET, mas na verdade fui contratado por minhas habilidades em Java / JRubyRails. Eu posso criar esse novo aplicativo em X por um período de tempo usando as ferramentas que eu já conheço. Eu poderia aprender C # / mvc4 como você quiser, mas levará >> X uma quantidade de tempo. O que você quer?

Isso levanta a questão das "habilidades que você foi (supostamente) contratadas para" vs. "habilidades que você precisa agora" e também mostra que você está disposto a aprender as novas habilidades, mas que será necessário mais tempo para desenvolver o novo aplicativo, pois você é novo neste conjunto de ferramentas. E você não quer mostrar que você está disposto a aprender novas habilidades. Não estar aberto a aprender novas habilidades é uma boa maneira de garantir que seu emprego termine quando suas habilidades não forem mais necessárias.

Quanto à sua pergunta no final:

Em que momento um desenvolvedor deve poder escolher suas ferramentas? Isso depende da empresa? Minha empresa é péssima ou isso é considerado normal? Existem pastos mais verdes? Estou vendo isso da maneira errada?

Geralmente depende da empresa. Se uma empresa compra ferramentas MS e padroniza tudo na plataforma VisualStudio e na estrutura .NET, pode ficar muito estranho se um desenvolvedor insistir em usar Linux e C. Isso é normal. Exceções podem existir onde a empresa é menos exigente com os editores, como permitir que os desenvolvedores escolham o Vi vs. Emacs, desde que a saída seja a mesma. Sei que algumas empresas até permitem que os desenvolvedores escolham Windows x Linux, mas o idioma em que trabalham tem um suporte e tempos de execução muito bons para os dois sistemas operacionais.

Por que as empresas fazem isso? Consistência é uma razão. Pode ser muito difícil depurar coisas quando o aplicativo é uma colcha de retalhos de binários criados nas linguagens / estruturas favoritas de vários desenvolvedores, construídas em ferramentas diferentes e testadas em sistemas muito diferentes. Se todos os desenvolvedores trabalhar em sua maioria set ups semelhantes, esses tipos de problemas são resolvidos.

No seu caso, parece que você foi contratado para trabalhar em uma tecnologia que não é padrão nesta empresa. Isso me parece estranho, e você pode querer conversar com a pessoa que o contratou sobre o motivo pelo qual eles queriam isso.

Em que momento um desenvolvedor deve poder escolher suas ferramentas?

Quando eles não impactam sua equipe.

Estou vendo isso da maneira errada?

Absolutamente.

Sim, você tem um prazo curto. Sim, você pode fazer isso mais rapidamente no Rails. Mas a empresa como um todo precisa implantar e manter o aplicativo. Se a empresa possui um bom número de desenvolvedores de C #, provavelmente será mais barato (e produzirá melhor qualidade) ter um aplicativo de C # para manter.

Seus DBAs e outra equipe administrativa provavelmente estão familiarizados com essa pilha e possuem processos para implantar e atualizar essa pilha. Mesmo que você consiga executar o código mais rapidamente, pode levar mais tempo depois que você contabilizar toda a sobrecarga necessária para instalar e executar um aplicativo Web profissional.

Lembre-se de que você gastará muito mais tempo mantendo seu aplicativo do que escrevendo. Otimize para esse custo.

1. Aparentemente, você foi contratado devido à sua capacidade de se adaptar às "novas" tecnologias. C # não é diferente, a esse respeito. Tem certeza de que não deseja aproveitar a oportunidade para aprender algo novo?

2. O ASP.NET MVC é muito semelhante ao Ruby on Rails, de várias maneiras.

3. Você não estará no ritmo de um caracol para sempre. Se você já conhece o ROR, o ASP.NET MVC será muito fácil para você. O truque é aprender C #.

Argumentos para permanecer no Java / JRuby

As chances são de que seu chefe queira que você produza. Eles o contrataram para que você pudesse agregar valor à empresa. Certifique-se de que eles entendam que, ao forçar o uso de uma estrutura que você não conhece, eles farão com que você:

1. Produza resultados a uma taxa mais lenta
2. Crie código de qualidade inferior

Até os melhores programadores requerem tempo de aquecimento com novas linguagens / estruturas.

Argumentos para aprender MVC4 e C #

Aprender novos idiomas é bom. Investir em suas habilidades como programador é apenas um risco se o idioma / plataforma que você está aprendendo desaparecer no futuro próximo e, com a Microsoft acompanhando, não acho que isso seja um problema. O C # e o MVC tiveram atualizações recentes melhorando os dois, com ainda mais atualizações no pipeline.

Tornar você, pessoalmente, um desenvolvedor mais bem-formado impedirá que você seja colocado nessa situação novamente. A melhor parte? Seu chefe pagará para você aprender essas coisas, o que significa que você é pago para ganhar mais dinheiro.

A linha inferior

Você pode acabar vencendo essa luta, mas ficará trabalhando com colegas insatisfeitos. Apenas explique os prós e os contras de cada um para o seu gerente e, em seguida, os dois sairão felizes do outro lado.

Em que momento um desenvolvedor deve poder escolher suas ferramentas?

Quando o desenvolvedor é o líder do software.

Certamente, você pode (e deve) defender o uso do kit de ferramentas diferente se estiver preocupado com a produtividade, mas esteja preparado para uma resposta que não lhe agrada. Pode haver uma boa razão para o seu lead querer que você use um kit de ferramentas específico, seja ele compatível com a arquitetura atual, preocupações com a manutenção, problemas de licenciamento etc.

BTW, a frase

com foco em fazer muitas coisas em um curto espaço de tempo

é responsável por mais azia e confusão na indústria de software do que praticamente qualquer outra coisa.

Observo que você não diz que foi contratado como programador JRuby ou Java.

Aqui está o porquê você disse que foi contratado: "[B] porque tenho muita experiência na criação de aplicativos Web e porque me apego a tecnologias mais novas, como JRuby on Rails ou nodejs".

Em outras palavras, eles gostam da sua experiência na Web e da sua vontade de aprender novas tecnologias.

Agora eles estão pedindo para você usar sua experiência na Web e aprender uma nova tecnologia.

Então a questão é: você vai fazer isso ou não?

A maior despesa em software está na manutenção dele

Eu li que a maior despesa (80%) está na manutenção de software. O desenvolvimento inicial é de apenas 20% do custo total do desenvolvimento.

Li um caso sobre um desenvolvedor que desenvolveu código e comentários em seu idioma nativo (não em inglês) e quando os outros membros da equipe aprimoraram e mantiveram o código, era quase impossível porque o idioma (não qualquer linguagem de programação) era estrangeiro para eles.

Da mesma forma, se você desenvolver código em uma linguagem de programação de sua própria escolha, seria difícil para outros membros da equipe manter.

Solução: Programação em pares

Considere pedir aos seus empregadores que o associem a alguém que conheça a linguagem de programação necessária e que você possa trabalhar juntos. Você pode aprender um com o outro e, se algum de vocês deixar a empresa, o outro saberá o código.

Artigo da Wikipedia sobre "Programação em pares": http://en.wikipedia.org/wiki/Pair_programming

Muitas empresas simplesmente preferem manter o que sempre fizeram ou o que é "seguro". Há uma razão pela qual Java e PHP ainda são muito populares. No momento, procurar por "COBOL" no Indeed.com retorna 2144 listagens ... que devem realmente falar por si. O setor não se preocupa com um bom código, se preocupa com o código que pode ordenhar pelo maior tempo possível (isso não implica que o C # seja ruim, realmente não é).

Pense nisso: o código vai durar mais que você. Há uma boa chance de alguém manter seu código e o C # é uma aposta mais segura que o Node.js e o Rails. Não me surpreenderia se, em 5 ou 6 anos, o número de programadores Ruby reduzisse para metade, depois de tudo o mesmo aconteceu com Perl e qualquer outra linguagem que tenha sido considerada em algum momento a linguagem web "it". É provável que o Javascript não desapareça, mas já estamos começando a vê-lo sendo usado como uma espécie de ASM (ou C) da Web - um idioma intermediário que outros idiomas podem compilar para que o código do servidor seja possível muito bem tornar-se obsoleto.

Minha principal preocupação com os desenvolvedores que escolhem como implementar seus objetivos é que eles normalmente assumem apenas que estarão editando o código. Veja dessa maneira: 12 meses depois, eles podem precisar de alterações; você não está disponível (saiu da empresa ou está realmente ocupado com outra tarefa) e outro desenvolvedor precisa agitar seu código. Se for uma loja em C #, usar o conjunto de ferramentas é um bom trabalho de equipe. Novas tecnologias devem ser investigadas e implementadas, mas apenas quando o líder pensa que é a hora certa, pois está de olho em muitos objetivos e não apenas em um.

Vire-o, por favor. Imagine que você contratou um desenvolvedor Ruby e eles insistem em implementar o trabalho deles no Asp.net/MVC.

O que você diria a eles? Esta é a nossa pilha, cara. Aprenda a viver com isso.

A regra de ouro, aqui está, quem tem o ouro faz as regras.

Existem vários objetivos conflitantes e o problema é encontrar o melhor compromisso. Temos o prazo final, temos um líder de equipe que solicita um determinado conjunto de ferramentas e temos um desenvolvedor inexperiente com esse conjunto de ferramentas, mas fadado a produzir algo dentro de um prazo (obviamente curto).

É importante entender que o líder da equipe provavelmente tem algumas boas razões pelas quais ele exige exatamente esse conjunto de ferramentas (uma das quais poderia ser realmente para você se acostumar com esse conjunto de ferramentas por algum motivo que você talvez ainda não saiba). A melhor coisa que você pode fazer na primeira execução é descobrir quais são exatamente esses motivos.

Colocado em sua posição, eu tentaria conversar com o líder da equipe e tentar explicar a situação, como é na sua opinião, e as opções e quais resultados (incluindo efeitos econômicos de curto e longo prazo) serão gerados seguindo cada uma dessas opções. Por exemplo, outro desenvolvedor mais experiente pode ser designado para orientá-lo, talvez com algumas sessões de programação em pares ou similares.

A menos que o líder de sua equipe seja um completo idiota, você deve encontrar um consenso que faça sentido em relação ao projeto e aos objetivos gerais da empresa.

Bah. Todo mundo está errado.

Seja um desenvolvedor melhor do que as pessoas de uma plataforma e você terá muito mais opções interessantes do que nunca. Então, por enquanto, aprenda MVC. E no seu tempo livre, aprenda mais sobre as plataformas que realmente lhe interessam. Crie suas habilidades em Nó. Aprenda um pouco de Django. Preste atenção em todas as travessuras Java ou pré-MVC .NET às quais você está exposto e depois foge, mas pelo menos aprenda o suficiente para poder criticar e explicar quanto pensamento você colocou no seu preconceito ardente e quase oculto dessas plataformas. (ok, talvez eu esteja projetando lá)

E agora para os conselhos importantes. Se você continuar aprimorando suas especialidades e também diversificando seus conhecimentos em outras áreas, estará em um lugar onde poderá encontrar novos trabalhos a qualquer época do ano, em menos de duas semanas, em qualquer cidade grande, fazendo coisas que são necessárias. principalmente interessante pelo menos metade do tempo. Quando você se encontrar neste lugar, não aceite esses empregos onde eles dizem que querem isso e, no segundo dia, eles o farão sem esperança de um alívio previsível no futuro a longo prazo. Apenas explique e peça desculpas educadamente, mas não, você realmente não queria fazer isso e disse o mesmo em sua entrevista e depois! @ # $ Ing parou e seguiu em frente quando algumas semanas passam e eles inevitavelmente não fizeram nada para acomodar o fato de que eles deturparam a posição para você e se recusam a reconhecer isso.

Mas confie em mim, encontrar um novo show é sempre muito melhor do que ficar seriamente irritado e infeliz por qualquer período de tempo que ultrapasse 5 minutos. Mas é claro, primeiro você tem que pagar suas dívidas para poder fazer isso. Algumas pessoas nunca o farão. É por isso que eles querem tudo o que sabem melhor. E é claro que outras respostas não estão realmente erradas. Faz sentido que uma loja .NET vá com o .NET se precisar manter a coisa boba.

Obviamente, o que não faz sentido é o motivo pelo qual eles se diversificam com um desenvolvedor do Rails / JS / UI e fazem com que ele faça apenas aplicativos MVC. Mas para agora. Pode ser necessário buscá-lo e pagar suas dívidas. E como eu disse nos comentários, o MVC não é tão ruim assim. Uma escolha muito ruim, dadas todas as opções, mas certamente não é a pior. É bem direto, não lança 10.000 camadas de abstração em cima de tudo o que realmente está acontecendo, e não fica tão distorcido com o lado do cliente que você amaldiçoaria os nomes dos engenheiros de MS responsáveis ​​se alguém pudesse se incomodar para aprendê-los.

Portanto, chegue ao local em que você pode sair quando quiser, se ainda não o fez e pode até achar que tem um olhar mais cético das coisas que atualmente gosta. Você pode até achar que não gosta de trilhos tanto quanto eu. Não que haja algo errado com Ruby (além do intérprete, é claro).

Dependendo da sua situação, pode ser perigoso supor que você sabe por que eles o contrataram e, ainda mais, supor que seu gerente saiba disso e concorda que contratar pessoas com suas habilidades é uma boa idéia.

Gostaria de pedir o conselho acima e apresentar um caso de negócios por que você deve usar o JRuby em C #, talvez seu argumento e cronograma signifiquem que romper com os métodos antigos faz sentido. Eu não iria apenas assumir que está tudo bem ou não, dar ao gerente ou liderar os fatos e deixá-los tomar a decisão, é o que eles estão pagando muito dinheiro, além de um pouco de CYA.

Na minha opinião sincera, uma das coisas que separa bons desenvolvedores de ótimos é sua capacidade de se adaptar às novas tecnologias. Vivemos em um mundo acelerado, onde a tecnologia de ponta de hoje se tornará obsoleta amanhã. Portanto, um desenvolvedor que não está disposto a se adaptar é de uso limitado para a empresa. Isso seria bom, se não fosse um pequeno fato de que encontrar e contratar pessoas boas é realmente realmente difícil de fazer e, quando uma empresa encontra sua jóia, ela está planejando a longo prazo.

Vi empresas contratando fora de seu escopo tecnológico e o fazem exatamente pelo mesmo motivo. Eles querem ter grandes desenvolvedores, mesmo que isso signifique esperar que eles se adaptem à nova tecnologia.

Agora para a sua situação. Como um novo cara no grupo, eu teria muito cuidado com o que digo e não digo aos meus superiores. Claro, você se sairá muito com base na suposição de que ainda está em um processo de adaptação ao seu novo ambiente. No entanto, minar a autoridade e perseverança obstinada na sua tecnologia preferida apenas fará com que seus superiores pensem que cometeram um erro ao contratá-lo e que você não está disposto a deixar sua zona de conforto.

O que você escolherá é com você, mas eu sugiro que você tente aprender novas tecnologias. Não vai doer, eu prometo.

Eu vou assumir que você foi honesto na entrevista durante sua entrevista sobre sua falta de conhecimento em C #, porque, se não fosse, talvez estivesse em uma posição muito precária do ponto de vista jurídico.

Bons programadores sabem programação. Embora ninguém possa obviamente ser versado em todas as linguagens e estruturas, existe uma semelhança considerável entre a maioria delas. A menos que você esteja sendo solicitado a trabalhar em um idioma que seja massivamente diferente do que constitui o mainstream atualmente (Lisp, por exemplo), um bom programador poderá se adaptar.

Naturalmente, há uma curva de aprendizado. Se o empregador o contratou, ele deve estar confiante em suas habilidades para seguir essa curva em um período de tempo razoável (novamente, assumindo que você foi honesto desde o início por não conhecer C #). A linguagem C # empresta muito do Java e, em geral, a maioria das linguagens de programação baseadas em classes é fundamentalmente bastante semelhante (você mencionou o node.js, que se baseia no ECMAScript, que é uma linguagem baseada em protótipo, então você obviamente confortável com outros paradigmas de programação.

Bons programadores devem, além de flexíveis, estar ansiosos para aprender coisas novas. No desenvolvimento de software, você geralmente está aprendendo ou se tornando irrelevante.

É claro que seu empregador, assumindo que sabia que você não conhecia C #, precisa conhecê-lo no meio do caminho. Se você demonstrar vontade de aprender, eles precisam fornecer tempo e recursos para isso. Jogá-lo no fundo do poço é injusto e desnecessariamente estressante. Você precisa sentar e ter uma discussão calma e racional com seu superior. Se eles querem isso em C #, devem estar preparados para aceitar que você estará em uma curva de aprendizado enquanto trabalha e será injusto que eles imponham prazos apertados a você. Se os prazos não forem flexíveis e forem de alta importância estratégica, eles deverão estar preparados para permitir uma certa latitude para que o trabalho seja realizado dentro desse prazo. Se eles precisarem que ele esteja no idioma mais usado no escritório, talvez você possa solicitar a implementação agora no que você ' esteja familiarizado com o cumprimento do prazo e, em seguida, como seu próximo projeto, reimplemente-o em C # como um exercício de aprendizado e para colocar o software em conformidade com os requisitos internos, uma vez que atenda aos externos. Como eu disse, a maioria das linguagens mais usadas hoje em dia tem muito em comum; portanto, a maioria se resume a detalhes da implementação.

Você precisa estar preparado para aceitar, mais cedo ou mais tarde, que você está trabalhando em uma loja de C # e, portanto, precisa ter o C # em seu currículo.

Talvez eles não estejam satisfeitos com a maneira como todos estão usando o MVC no ambiente .NET. Pode haver muito tratamento como formulários da web. Isso não é diferente quando alguém com experiência em procedimentos começa no OOP, coloca tudo em uma grande classe e continua os negócios como de costume.

Este primeiro projeto não é a situação ideal, porque eles querem que isso seja feito tão rapidamente. Mantenha a velocidade do .NET o máximo possível e inicie os recursos o mais rápido possível. Você não vai gostar do jeito que está fazendo as coisas, apenas lembre-se de que você começará a refatorar essas coisas e aplicar suas habilidades em outro idioma.

Felizmente, sua maneira de usar o MVC4 (assumindo que todos os outros não estão fazendo isso direito) em um estilo mais Ruby irá capturar e afastar todos da mentalidade dos Webforms.