Uma ordem da empresa para mudar para um determinado IDE é uma bandeira vermelha? [fechadas]

Entrei recentemente para uma startup que cresce rapidamente. Nos últimos 3 meses, a equipe de desenvolvimento aumentou de 4 para 12. Até agora, eles eram muito laissez-faire sobre o que os desenvolvedores costumavam fazer seu trabalho. De fato, uma das coisas que inicialmente achei atrativa na empresa é que a maioria dos programadores usava Linux, ou qualquer SO que eles sentissem mais adequado aos seus esforços.

Agora, pedidos, sem discussão, chegaram à conclusão de que todos devem mudar para o Eclipse. Um bom editor. Eu prefiro o SublimeText2, mas é apenas o meu gosto pessoal.

Só para esclarecer: somos uma equipe de JS que usa o Backbone e o Eclipse simplesmente não é bom para entender o código do Backbone. Isso significa que aqueles da equipe que usam um / good / IDE (PHP Storm) precisam voltar a fazer muitas coisas do tipo procurar-encontrar-oh-espere-onde-estava-há-três-etapas-atrás em vez de apenas pressionar Ctrl + clicar e usar retroceder / avançar - provavelmente diminuindo a produtividade em 15% e o prazer em 50% ...

Isso é uma bandeira vermelha? Parece caprichoso e irracionalmente controlar dizer aos desenvolvedores (que não são do MS) que IDE ou conjunto de ferramentas usar se já estiverem estabelecidos e produtivos.

"Agora chegaram as ordens, sem discussão , de que todos devem mudar para o Eclipse".

Eu acho que essa é a verdadeira bandeira vermelha. Sua equipe é especialista em desenvolvimento de software e aquela a ser afetada pela decisão e, no entanto, você não conseguiu dizer uma palavra na discussão que resultou nessa ordem?

Soa como administrar demais os chefes de cabelos pontudos. A pessoa / equipe responsável pela tomada de decisão tem informações relevantes para essa decisão?

Dado que os tomadores de decisão são qualificados o suficiente para tal decisão, não pedir a opinião da equipe de desenvolvimento tem pelo menos duas deficiências:

• A equipe não se sente envolvida. Envolver a equipe deve ser uma prioridade para a gerência. Eu não gostaria de trabalhar como desenvolvedor em algum lugar em que minha opinião sobre questões centrais como o IDE não seja valorizada o suficiente para ser solicitada. Concedido que pedir a opinião de alguém e depois decidir contra ela pode ser pior, mas nesse caso eu esperaria uma lógica sólida para essa decisão.

• A gerência, por mais experiente que seja, não trabalha 100% com o desenvolvimento desse código específico. Supondo que as pessoas que não têm uma visão interessante sejam ingênuas. Claro que pode ser que os gerentes tenham pensado em tudo o que os desenvolvedores criam, mas a única maneira de saber é perguntar.

É razoável que, ao trabalhar juntos em um projeto comum, em todas as estações de trabalho você tenha todas as ferramentas disponíveis para editar / criar / depurar seu software e que as principais ferramentas para realizar cerca de 90% do desenvolvimento sejam conhecidas por todos O time. É mais difícil alcançar esse objetivo se sua equipe estiver crescendo e todos usarem seu conjunto de ferramentas favorito pessoal - quanto mais pessoas, mais opiniões. E o trabalho administrativo também fica mais fácil se você não deixar o número de ferramentas crescer mais do que o necessário.

Obviamente, se um desenvolvedor insistir em usar seu editor favorito pessoal, isso pode ser aceitável, desde que ele possa garantir que a fonte não pareça ou se comporte de maneira diferente no editor principal da equipe (no seu caso, Eclipse), por isso, se dev B precisa editar a fonte de dev A, dev B não deve ser forçado a aprender o editor favorito pessoal de A para poder alterar a fonte efetivamente. Mas cuidado, se os dois tiverem que trabalhar juntos de vez em quando na frente do mesmo monitor (ou fazer alguma programação em pares), as coisas serão mais fáceis se o editor escolhido for bem conhecido por ambos.

Para fins de programação em pares, é bom que ambas as partes na frente da tela tenham as mesmas habilidades ao usar o teclado. Também é bom saber que, se o seu projeto tem necessidades especiais de configuração no IDE, é configurado da mesma maneira para todos. Começar um novo desenvolvedor é mais fácil quando as ferramentas são iguais para todos.

Mas se você comparar isso com apenas tentar ser mais eficaz, não vale a pena

Sim, é um sinal de que a administração se considera um juiz melhor de quais ferramentas você seria mais eficiente do que você.

Não é uma bandeira vermelha em si.

Às vezes, a gerência precisa tomar decisões . Quaisquer questões que exijam padronização em algo tendem a se enquadrar nessa categoria. Certa vez, trabalhei em um cliente que permitiu que os padrões se desviassem por alguns anos e eles tinham mais de 20 ferramentas SCM diferentes. O que começou como uma escolha independente por diferentes equipes de desenvolvimento se transformou em um pesadelo logístico que dificultou severamente o compartilhamento de habilidades e a colaboração no código em toda a organização. A compilação integrada foi ..... er ..... não muito integrada .....

Além disso, não é prático ou necessário consultar todos para cada decisão . A extensão em que isso precisa ser feito depende da cultura da organização e da importância / complexidade da decisão. Normalmente, você usaria uma destas opções menos pesadas de consulta:

1. Tome a decisão você mesmo, se você tiver conhecimento suficiente dos prós / contras e não for uma decisão importante o suficiente para exigir uma ampla consulta.
2. Consulte algumas pessoas importantes (que provavelmente seriam os desenvolvedores seniores mais qualificados para tomar a decisão).
3. Aumente o fato de que você está tomando uma decisão para todos que possam ser afetados (email, reunião da prefeitura, reuniões da equipe). Diga qual você acha que é a decisão certa, mas que deseja mudar isso se surgirem novas evidências em contrário. Convide as pessoas a se apresentarem individualmente se tiverem visões importantes
4. Convide pessoas para formar uma subequipe para revisar as opções e recomendar uma decisão. Boa opção, se for realmente por um triz, você não sabe a resposta e deseja que os envolvidos sejam incluídos na decisão.

Para algo como ferramentas para desenvolvedores (que é um problema potencialmente controverso) eu provavelmente faria 2 seguidos por 3 ou 4. ou seja, haveria definitivamente algumas pessoas com quem eu não conversaria pessoalmente sobre o assunto, mas, por outro lado, a maioria das pessoas-chave teria a chance de contribuir para a tomada de decisão.

Para mim, a verdadeira bandeira vermelha estaria por aí se você sentir fortemente que a decisão errada foi tomada (errado == isso prejudica a empresa e não apenas a sua ferramenta favorita não será escolhida). Como o gerenciamento reage quando você levanta esse problema:

• A boa gerência ouvirá seu argumento, sinceramente, obrigado pelo feedback e reconsidere sua posição no caso de você ter levantado novas idéias . Eles ainda podem não concordar com você e podem manter sua decisão, mas eles apreciarão que você o tenha levantado com eles e terão a cortesia de dizer por que eles estão mantendo sua decisão. Eles podem até mudar a maneira como tomam essas decisões no futuro, e se você fez bons comentários, pode incluí-lo na lista de "pessoas inteligentes para perguntar".
• A má administração ficará na defensiva, diga que "a decisão foi tomada" e outras táticas para evitar enfrentar o fato de que eles podem ter tomado uma decisão errada. Eles podem vê-lo como um "causador de problemas". A empresa sofre, assim como sua fé na administração. Esta é uma verdadeira bandeira vermelha! Saia enquanto pode!

Se você estiver usando o maven ou algo semelhante, não importa qual IDE você está usando. Pode haver casos em que alguém esteja vinculado a um IDE específico, como eclipse, se houver plugins nos quais você confia.

Eu acho que você deve poder escolher seu próprio IDE, o IDE em que é mais produtivo. No entanto, como já afirmei, há casos em que faz sentido usar um IDE padrão.

Eu teria o IDE "corporativo" instalado, mas ainda faria a maior parte do meu trabalho em qualquer IDE que eu quisesse - não é como se alguém soubesse qual IDE foi usado para editar um arquivo de origem.

Na frente do IDE vs. do editor ... para quase todas as linguagens, prefiro fortemente um IDE (IntelliJ) porque há muito mais que ele pode fazer por você do que um editor. Há algumas coisas pelas quais eu reverto para o ST2 ou o Emacs, mas, para a codificação diária, apesar do quanto eu gosto do ST2 / Emacs, o IDE quase sempre vence.

Cada equipe em que participei teve uma multiplicidade de IDE e editores: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - nunca foi um problema. Nunca.

Para mim, isso fala de um mal-entendido nos altos níveis da organização, sobre o que realmente importa. O que importa é deixar que os bons codificadores façam o que precisam e usar as ferramentas que os tornam mais confortáveis. A uniformidade do IDE tem muito pouco a ver com a comunicação real que ocorre sobre as questões essenciais da arquitetura de objetos, teste de unidade, algoritmos etc.

Ter o mesmo IDE que o próximo cara significa apenas que nós dois sabemos como navegar pelo código com os mesmos atalhos e como nossa compilação / configuração é definida. Nada disso importa ao falar sobre problemas reais de código.

Olha, é habitável, dependendo de outros fatores da empresa. Você sempre pode usar seu próprio editor preferido para as coisas do dia-a-dia. E talvez o seu grupo esteja fazendo outras grandes coisas que criem uma grande cultura. Porém, os IDEs obrigatórios são um IMO de grande passo em falso. Para mim, se eu estivesse entrevistando uma empresa e eles me informassem qual IDE eu poderia usar, agradeceria educadamente a eles pelo tempo dispensado.

Em nossa loja Ruby, há uma forte recomendação de usar o IDE que a maioria da equipe desfruta (RubyMine), porque sabemos que ele faz o trabalho e podemos ensinar uns aos outros atalhos etc.

Os desenvolvedores são livres para usar um IDE diferente, mas exigimos que eles tenham habilidades sólidas nesse editor, caso assim o desejem. Se vemos alguém lutando para navegar em seu projeto ou editar texto em seu FooEdit personalizado, o RubyMine é para eles.

Se um programador é especialista em um determinado IDE, ele deve usá-lo. Se eles não são especialistas em qualquer IDE, provavelmente há um ou dois que são muito comuns para sua linguagem de programação ou dentro de sua equipe, e provavelmente faz sentido que eles aprendam.

Ser forçado a padronizar um IDE parece uma péssima ideia.

As razões para uma empresa forçar um editor ou software em geral em seus desenvolvedores devem ser examinadas. A parte paranóica (talvez não a palavra que estou procurando) pensa que pode haver algum tipo de rastreamento de produtividade adicionado ao eclipse que eles estão pedindo aos desenvolvedores para instalar. Um pensamento muito menos paranóico (novamente) seria que eles gastaram tempo adicionando ferramentas de criação de produtos a esse IDE que facilitariam muito as coisas se todos pressionassem o mesmo botão para testar e criar sua ramificação de código.

De qualquer forma, o que estou tentando dizer é provavelmente mais do que mera burocracia ou um método de mexer com os chefes dos desenvolvedores.

Esta é uma bandeira vermelha enorme. Toda empresa tem algumas idéias estúpidas, mas se outras bandeiras vermelhas continuarem chegando, apenas saia.

É fácil que a motivação por trás de algumas decisões se perca - especialmente com a equipe em rápido crescimento. A motivação para migrar para o Eclipse pode ser apenas o fato de que a maioria dos desenvolvedores parece estar perdendo muito tempo apenas configurando o IDE e que há apenas um conhecimento limitado na sua empresa.

Gostaria apenas de encomendar a mudança para o Eclipse para indicar que você deve ter a configuração do Eclipse, caso seja necessário, mas continue seu trabalho no seu editor favorito. (Talvez você precise mudar para o Eclipse gradualmente se sua empresa começar a implementar ferramentas interessantes no Eclipse.)

Bandeira Vermelha: Eu esperaria se houvesse mais algumas ordens irracionais antes de me preocupar.

Uma startup geralmente tenta permanecer ágil por tempo suficiente para descobrir um modelo de negócios sustentável. Depois de descobrir a parte do dinheiro, a gerência se move para ampliar os negócios. É geralmente quando todos os funcionários de tecnologia começam a sair, à medida que os processos de engenharia ficam mais rígidos.

Como você sabe, você não sabe o que o código realmente fará até executá-lo. Turing provou isso nos primeiros dias da computação. Isso significa que não existe uma medida significativa de produtividade quando se trata de escrever software. No entanto, para que a gerência faça seu trabalho, a produtividade deve ser legível. Como você não pode medir o código (e as pessoas tentaram - linhas de código, por exemplo), elas medem o que podem ver. Os programadores são mais legíveis do que o software que desenvolvem. A equipe de gerenciamento típica tenta controlar os programadores, a fim de tornar essas coisas legíveis para eles (em vez de fazer seu trabalho real: sair do caminho). E porque eles medem as coisas erradas, isso não funciona muito bem.

Dito isto, você ainda pode percorrer um longo caminho com uma equipe fracamente acoplada. A equipe de desenvolvimento do Github tem cerca de 50 pessoas e elas quebram todas as regras nos manuais de gerenciamento de negócios. Eles parecem estar bem. Os erros são corrigidos (eventualmente). Recursos são adicionados. Os incêndios são apagados.

O que é uma grande bandeira vermelha é se eles estão tentando ampliar as coisas sem ter descoberto como ganhar dinheiro. Nesse ponto, você deve se perguntar quanto de suas opções e subvenções não investidas realmente vale a pena.

Certamente esta é uma má ideia. É inevitável que a equipe se torne menos produtiva, pois eles precisam aprender a usar novas ferramentas. E, mesmo assim, eles não serão tão eficazes quanto com as ferramentas que já possuem .

Desde que eu mesmo tentei várias ferramentas, sempre tive a sensação de que "Deus, esse editor está me irritando com <insira algum bug / diferença da ferramenta preferida>". Portanto, também será uma desvantagem moral.

Mas é claro que também existem profissionais para que uma equipe inteira use as mesmas ferramentas. Compartilhar configurações, skripts, plugins e todo esse tipo de coisa. O que não seria possível com uma diversidade de conjuntos de ferramentas.

Por outro lado ... esse último pedaço não seria necessário se todos usassem seu software preferido. ;)

Você pode "usar" o Eclipse enquanto ainda digita SublimeText2.

Isso significa ter o Eclipse instalado e configurado para seus projetos e ficar atualizado com ele para que você fique igualmente confortável em usá-lo se, por exemplo, emparelhar a programação. Ninguém (ou pelo menos deveria) se importa com o editor que você realmente digitou em um pedaço de código que você cometeu, desde que a manutenção da configuração paralela não leve muito tempo e você não se afaste do ambiente de desenvolvimento padrão.

Se você estiver usando o Git e sua ramificação estiver desativada, não precisará usar os editores um do outro. Você pode simplesmente empurrar um ramo e pedir a outro desenvolvedor para fazê-lo funcionar, se ele realmente não conseguir entender o seu conjunto de ferramentas. Forçar todo mundo a usar o mesmo editor soa como um pedido de algum chefe de negócios que quer parecer inteligente, mas realmente não entende o modo como vocês operam.

Se você pensa sobre isso do ponto de vista do gerenciamento, a razão pela qual eles podem estar fazendo isso é a conformidade legal. A empresa é responsável por garantir que todas as ferramentas usadas estejam sendo usadas legalmente e também não sobrecarregarão o produto que está sendo desenvolvido. (Alguns editores são gratuitos para uso pessoal, mas não são gratuitos para outros fins, etc.) Auditar todas as ferramentas que todo desenvolvedor pode querer usar pode ser caro. Eu já vi que em projetos em que os prazos são apertados, o gerenciamento será cauteloso sobre quais ferramentas / bibliotecas / etc são usadas para minimizar as alterações mais tarde no projeto, que são direcionadas pelas pessoas jurídicas.

Em projetos de maior segurança, há também a preocupação de onde os IDEs armazenam arquivos temporários e quais informações são armazenadas entre as sessões.

Tudo depende dos motivos pelos quais eles recomendam o Eclipse. Se os desenvolvedores estão tendo problemas para configurar seus ambientes porque todos organizam as coisas de maneira diferente, pode haver um motivo para recomendar uma camisa de força. Se, no entanto, todos estavam felizes e produtivos usando o que queriam, há poucas razões para impor uma mudança em algo tão profundamente envolvido no processo criativo.

O Eclipse é muito mais que um editor - você pode continuar usando seu editor favorito para editar seu código e confiar no Eclipse para controle de origem, depuração e qualquer outra coisa que o fluxo de trabalho obrigatório da empresa desejar.

Uma coisa final - o processo de imposição nesse nível pode indicar que a empresa pretende expandir a equipe de desenvolvimento e deseja ter uma certa estrutura para que novos colegas de equipe possam se tornar produtivos mais rapidamente. Se você acha que o Rails (ou Django) é uma estrutura "opinativa", você perceberá que a estrutura ajuda a entender as novas aplicações com mais facilidade.

A bandeira vermelha não é tanto que um único editor / IDE esteja sendo imposto a todos os desenvolvedores, mas essa decisão, e especialmente a decisão sobre a qual o IDE / editor deveria ser usado, não foi tomada por todos os desenvolvedores, e talvez nenhum eles!?!

Certamente, seria melhor para os desenvolvedores chegarem a um consenso, especialmente porque eles são obviamente os mais qualificados para a decisão (pelo menos em qual editor / IDE). Pode haver boas razões para se conformar e essa decisão deve pesar na preferência do gerenciamento, mas qual editor / IDE deveria ter sido a decisão de todos os desenvolvedores.

Seria fácil conseguir 12 desenvolvedores para votar. Certamente houve tempo suficiente para fazer isso! De qualquer forma, a conclusão teria sido dolorosa para alguns, e pode até acabar sendo Eclipse no final, mas rotular o requisito como uma "bandeira vermelha" nesse caso seria muito mais discutível.