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

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

I know you guys are a .NET shop, but I was actually hired for my Java/JRubyRails skills. I can build this new application in X amount of time using those tools that I already know. I could learn C#/mvc4 like you want, but it will take >> X amount of time. What do you want?

Isso levanta a questão de "habilidades que você foi (presumidamente)" contratou "para" versus "habilidades que você precisa agora" e também mostra que você está disposto a aprender as novas habilidades, mas que ele irá demorar mais para desenvolver o novo aplicativo, já que você é novo nesse conjunto de ferramentas. E você faz quer mostrar que está disposto a aprender novas habilidades. Não estar aberto para 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:

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

Geralmente depende da empresa. Se uma empresa compra ferramentas da Microsoft e padroniza tudo na plataforma VisualStudio e no .NET, pode ficar muito complicado se um desenvolvedor insistir em usar o Linux e o C. Isso é normal. Exceções podem existir onde a empresa é menos exigente com relação aos editores, como permitir que os desenvolvedores escolham o Vi vs. Emacs, desde que a saída seja a mesma. Eu sei que algumas empresas até deixam os desenvolvedores escolherem o Windows versus o Linux, mas a linguagem em que trabalham tem muito bons suporte e tempo de execução para ambos os sistemas operacionais.

Por que as empresas fazem isso? Consistência é um dos motivos. Pode ser muito difícil depurar as coisas quando o aplicativo é uma colcha de retalhos de binários criados nas linguagens / estruturas favoritas de vários desenvolvedores, construídos em diferentes ferramentas e testados em sistemas muito diferentes. Se todos os desenvolvedores trabalharem em principalmente configurações semelhantes, esses tipos de problemas serão resolvidos.

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

At what point should a developer be allowed to choose his tools?

Quando eles não afetam sua equipe.

Am I looking at this the wrong way?

Absolutamente.

Sim, você tem um prazo curto. Sim, você poderia fazê-lo mais rápido no Rails. Mas a empresa como um todo precisa implantar e manter o aplicativo. Se a empresa tiver um bom conjunto de desenvolvedores C #, provavelmente será mais barato (e produzirá melhor qualidade) ter um aplicativo C # a ser mantido.

Seus DBAs e outros funcionários do administrador provavelmente estão familiarizados com essa pilha e têm processos implementados para implantar e atualizar a pilha . Mesmo que você consiga fazer o código com mais rapidez, pode levar mais tempo, uma vez que você é responsável por toda a sobrecarga necessária para ativar e executar um aplicativo da Web profissional.

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

1. Você foi aparentemente contratado por causa de sua capacidade de se adaptar a "novas" tecnologias. C # não é diferente, a esse respeito. Tem certeza de que não quer aproveitar a oportunidade para aprender algo novo?

2. O ASP.NET MVC é muito semelhante ao Ruby on Rails, em muitos aspectos.

3. Você não ficará 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 ficar com o Java / JRuby

As possibilidades são, seu chefe quer que você produza. Eles contrataram você para que você pudesse agregar valor à empresa. Certifique-se de que eles entendem que, ao forçar você a usar uma estrutura com a qual você não está familiarizado, isso fará com que você:

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

Mesmo os melhores programadores precisam de tempo de aquecimento com novas linguagens / frameworks.

Argumentos para Aprendizagem MVC4 e C #

Aprender novas linguagens é bom. Investir em suas habilidades como programador é apenas um risco se a linguagem / plataforma que você está aprendendo vai desaparecer no futuro próximo, e com a Microsoft avançando, eu não acho que isso seja um problema. O C # e o MVC tiveram atualizações recentes melhorando ambos, com ainda mais atualizações no pipeline.

Fazer de você, pessoalmente, um desenvolvedor mais completo evitará que você seja colocado nessa situação novamente. A melhor parte? Seu chefe estará lhe pagando para aprender essas coisas, o que significa que você é pago para ganhar mais dinheiro.

A linha de fundo

Você pode acabar ganhando essa luta, mas você vai ficar trabalhando com colegas descontentes. Apenas explique os prós e contras de cada um ao seu gerente e, em seguida, vocês dois sairão do outro lado mais felizes.

At what point should a developer be allowed to choose his tools?

Quando o desenvolvedor é o líder de 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 da qual não goste. Pode haver uma boa razão pela qual seu líder deseja que você use um kit de ferramentas específico, seja a compatibilidade com a arquitetura atual, preocupações sobre manutenção, problemas de licenciamento, etc.

BTW, a frase

with a focus on getting a lot of stuff done in a short amount of time

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

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

Eis porque você disse que foi contratado: "Porque eu tenho muita experiência em construir aplicações web e porque eu me apóio em novas tecnologias como JRuby on Rails ou nodejs".

Em outras palavras, eles gostam da sua experiência na web e da sua disposição para aprender novas tecnologias.

Agora, eles solicitam que você use sua experiência na web e aprenda uma nova tecnologia.

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

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

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

Eu li um caso sobre um desenvolvedor que desenvolveu código e comentários em sua língua nativa (não em inglês) e quando os outros membros da equipe foram aprimorar e manter o código, isso ficou quase impossível porque a linguagem (não qualquer linguagem de programação) ) era estranho para eles.

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

Solução: programação em par

Considere pedir aos seus empregadores que o emparelhem com alguém que conheça a linguagem de programação necessária e trabalhe em conjunto. Você pode aprender um com o outro, e se qualquer um de vocês deixar a empresa, o outro saberá o código.

Artigo da Wikipédia sobre "Programação em Par": link

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, a pesquisa por "COBOL" em indeed.com retorna 2144 listagens ... que realmente deveriam falar por si. A indústria não se preocupa com o código bom, ele se preocupa com o código que pode produzir o máximo de tempo possível (isso não significa que o C # seja ruim, na verdade não é).

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

Minha principal preocupação com os desenvolvedores que escolhem como implementar seus objetivos é que eles normalmente assumem que somente eles estarão editando o código. Olhe para isto desta maneira, 12 meses depois eles podem precisar de mudanças; você não está disponível (deixou a empresa ou realmente ocupado em outra tarefa) e outro desenvolvedor precisa agitar seu código. Se é uma loja C #, então usando o seu conjunto de ferramentas é um bom trabalho em equipe. Novas tecnologias devem ser investigadas e implementadas, mas apenas quando o líder acha que a hora é certa, já que eles estão de olho em muitos objetivos e não apenas em um.

Ligue, por favor. Imagine que você é quem está contratando um desenvolvedor Ruby, e eles insistem em implementar seu trabalho 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 é, ela que tem o ouro faz as regras.

Existem vários objetivos conflitantes e o problema é encontrar o melhor compromisso. Temos o prazo, temos um líder de equipe que solicita um determinado conjunto de ferramentas e temos um desenvolvedor inexperiente com esse conjunto de ferramentas, mas condenado 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 (um dos quais poderia ser de fato 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 corrida é descobrir quais são exatamente essas razões.

Coloque em sua posição, eu tentaria falar com o líder da equipe e tentar explicar a situação, como está na sua opinião, e as opções e qual resultado (incluindo efeitos econômicos de curto e longo prazo). será gerado após cada uma destas opções. Por exemplo, outro desenvolvedor mais experiente poderia ser designado para treiná-lo, talvez com algumas sessões de programação em pares ou algo parecido.

A menos que o líder de sua equipe seja um idiota completo, você deve ser capaz de 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á opções muito mais interessantes do que elas. Então, por enquanto, aprenda MVC. E no seu próprio tempo, aprenda mais sobre as plataformas que realmente lhe interessam. Construa suas habilidades no Node. Aprenda um pouco de Django. Preste atenção em qualquer shenanigans Java ou pré MVC .NET que você está exposto e então corra, mas pelo menos aprenda o suficiente para ser capaz de criticar e explicar o quanto você pensou em seu preconceito mal-intencionado de ódio a essas plataformas. (ok, talvez eu esteja projetando lá)

E agora, o importante conselho. Se você continuar a aperfeiçoar suas especialidades enquanto também diversifica seus conhecimentos em outras áreas, você acabará por estar em um lugar onde poderá encontrar novos trabalhos em qualquer época do ano em menos de duas semanas em qualquer cidade importante, fazendo coisas que sejam principalmente interessante pelo menos metade do tempo. Quando você se encontra neste lugar, não ature esses trabalhos onde eles dizem que querem isso e no segundo dia eles fazem isso sem esperança de um alívio previsível no futuro a longo prazo. Apenas educadamente explicar e pedir desculpas, mas não você realmente não queria fazer isso e disse tanto em sua entrevista e, em seguida, @ # $ ing sair e seguir em frente quando um par de semanas passar e eles, inevitavelmente, não fizeram nada para acomodar para o fato de que eles deturparam a posição para você e se recusaram a reconhecer isso.

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

Claro, o que não faz sentido é por que eles diversificaram com um desenvolvedor Rails / JS / UI e só o fizeram fazer aplicativos MVC. Mas para agora. Você pode precisar buscá-lo e pagar suas dívidas. E como eu disse nos comentários MVC realmente não é tão ruim assim. Uma escolha muito ruim, dada todas as opções, mas certamente não é o pior. É bem direto, não gera 10.000 camadas de abstração sobre tudo que está realmente acontecendo, e não se torna tão distorcido com o lado do cliente que você amaldiçoaria os nomes dos engenheiros da MS responsáveis se alguém pudesse ser incomodado para aprendê-las.

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

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

Gostaria de pedir o conselho acima e fazer um caso de negócio por que você deve ir com JRuby sobre C #, talvez seu argumento e cronogramas significa quebrar as velhas formas faz sentido. Eu não iria apenas assumir que está tudo bem ou não, dar o gerente ou levar os fatos e deixá-los tomar a decisão, é o que eles estão sendo pagos as quantias chorudas para, além de seu um pouco de CYA.

Na minha opinião sincera, uma das coisas que separa os bons desenvolvedores dos grandes é sua capacidade de se adaptar à nova tecnologia. Estamos vivendo em um mundo acelerado, onde a tecnologia de ponta de hoje se tornará obsoleta amanhã. Assim, um desenvolvedor que não está disposto a se adaptar é de uso limitado para a empresa. Isso seria bom, se não fosse por um pequeno fato de que encontrar e contratar pessoas boas é realmente muito difícil de fazer e quando uma empresa encontra sua gema, elas estão planejando para o longo prazo.

Eu tenho visto empresas contratando fora de seu escopo de tecnologia e elas o fazem exatamente pelo mesmo motivo. Eles querem colocar as mãos em grandes desenvolvedores, mesmo que isso signifique esperar que eles se adaptem à nova tecnologia.

Agora, para a sua situação. Como um cara novo no grupo, eu teria muito cuidado com o que digo e não digo aos meus superiores. Claro, você vai se safar muito com base no pressuposto de que ainda está em processo de adaptação ao novo ambiente. No entanto, minar a autoridade e perseverança teimosa em sua tecnologia preferida fará com que seus superiores pensem que erraram ao contratar você e que você não está disposto a sair da sua zona de conforto.

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

Bons programadores sabem programar. Embora ninguém possa, obviamente, ser bem 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 uma linguagem que é maciçamente diferente do que constitui o mainstream atualmente (Lisp, por exemplo), então um bom programador deve ser capaz de se adaptar.

Naturalmente, há uma curva de aprendizado. Se o empregador contratou você, então eles devem estar confiantes em suas habilidades para seguir essa curva em um período de tempo razoável (novamente, assumindo que você foi honesto na frente de não saber C #). A linguagem C # usa muito o Java, e em geral, a maioria das linguagens de programação baseadas em classes é fundamentalmente bastante similar (você mencionou node.js, que é baseado no ECMAScript, que é uma linguagem baseada em protótipos, então você está obviamente confortável com outros paradigmas de programação.

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

É claro que o seu empregador, assumindo que eles sabiam que você não conhecia o C #, tem que encontrá-lo no meio do caminho. Se você demonstrar vontade de aprender, eles terão que dar tempo e recursos para isso. Atirar você no fundo do poço é injusto e desnecessariamente estressante. Você precisa se sentar e ter uma discussão calma e racional com seu superior. Se eles querem em C #, então eles devem estar preparados para aceitar que você estará em uma curva de aprendizado enquanto trabalha nisso e seria injusto para eles impor prazos apertados para você. Se os prazos não são flexíveis e se eles são de alta importância estratégica, então eles precisam estar preparados para permitir-lhe alguma latitude para fazer o trabalho dentro desse prazo. Se eles precisarem estar na linguagem mais comumente usada em seu escritório, talvez você possa solicitar a implementação agora no que você está familiarizado para cumprir o prazo e, em seguida, como seu próximo projeto reimplementá-lo em C #. como um exercício de aprendizado e para colocar o software em conformidade com os requisitos internos, uma vez que ele atenda aos requisitos externos. Como eu disse, a maioria das linguagens mais comumente usadas hoje em dia tem muito em comum, por isso, na maioria das vezes, os detalhes da implementação.

Você tem que estar preparado para aceitar, mais cedo ou mais tarde, que você está trabalhando em uma loja C # e, portanto, você precisa ter C # em seu cinto.

Talvez eles não estejam satisfeitos com o modo como todos estão usando o MVC no ambiente .NET. Pode haver muito tratamento como webforms. Isso não é diferente quando alguém com um histórico de procedimento começa em OOP, coloca tudo em uma grande turma e continua com os negócios normalmente.

Este primeiro projeto não é a situação ideal porque eles querem que isso seja feito tão rapidamente. Familiarize-se com o .NET o máximo possível e comece a colocar em funcionamento os recursos o mais rápido que puder. Você não vai gostar do jeito que está fazendo as coisas, apenas tente manter em mente que vai começar a refatorar essas coisas e aplicar suas habilidades em outro idioma.

Esperançosamente, a sua maneira de usar o MVC4 (assumindo que todos os outros não estão fazendo isso corretamente) em um estilo mais Ruby vai pegar e afastar todos da mentalidade de Webforms.