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

"Agora pedidos, sem discussão , concluímos que todos devem mudar para o Eclipse."

Acho que isso é a verdadeira bandeira vermelha. Sua equipe é especialista em desenvolvimento de software e aquela que será afetada pela decisão, e ainda assim você não conseguiu dizer uma palavra na discussão que resultou nesse pedido?

Parece super-gerenciamento por chefes de cabelos pontudos. A pessoa / equipe de tomada de decisão tem uma visão relevante 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 falhas:

• A equipe não se sente envolvida. Envolver a equipe deve ser uma prioridade para o gerenciamento. Eu não gostaria de trabalhar como um dev em algum lugar onde minha opinião sobre questões tão centrais como a IDE não é valorizada o suficiente para ser pedida. Admitindo que pedir a opinião de alguém e depois decidir contra ela pode ser pior, mas nesse caso eu esperaria uma base sólida para essa decisão.

• O gerenciamento, embora experiente, não funciona 100% com o desenvolvimento deste código específico. Assumindo que as pessoas que não têm uma visão interessante seriam ingênuas. É claro que pode ser que os gerentes tenham pensado em tudo o que os desenvolvedores inventam, mas a única maneira de saber é perguntar.

É razoável que, quando você trabalha em conjunto em um projeto comum, em todas as estações de trabalho você tenha todas as ferramentas disponíveis para editar / construir / depurar seu software, e que as principais ferramentas para fazer cerca de 90% do desenvolvimento sejam conhecidas. para todos na equipe. Esse objetivo é mais difícil de alcançar se sua equipe está crescendo e todos usam seu conjunto de ferramentas favorito - quanto mais pessoas, mais opiniões. E o trabalho administrativo fica mais fácil também, se você não permitir que o número de ferramentas cresça mais do que o necessário.

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

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

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

Sim, é um sinal de alerta que a gerência se considera melhor para avaliar com quais ferramentas você seria mais eficiente do que você.

Não é uma bandeira vermelha em si.

Às vezes, o gerenciamento precisa tomar decisões . Qualquer problema que exija padronização em algo tende a se enquadrar nessa categoria. Certa vez, trabalhei em um cliente que permitia 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. Compilação integrada foram ..... er ..... não muito integrado .....

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

1. Tome a decisão, se você tem conhecimento suficiente dos prós e contras e não é uma decisão suficientemente importante para exigir ampla consulta.
2. Consulte alguns indivíduos importantes (que provavelmente seriam os desenvolvedores seniores mais qualificados para tomar a decisão).
3. Aumentar o fato de que você está tomando uma decisão para todos que podem ser afetados (e-mail, reunião da prefeitura, reuniões de equipe). Diga o que você acha que é a decisão certa, mas que você está disposto a mudar isso se novas evidências surgirem do contrário. Convide as pessoas a se apresentarem individualmente se tiverem algumas visões importantes
4. Convide as pessoas para formar uma sub-equipe para analisar as opções e recomendar uma decisão. Boa opção se for genuinamente uma chamada de perto, você não sabe a resposta e quer que os envolvidos sejam comprados na decisão.

Para algo como ferramentas de desenvolvedor (que é um assunto potencialmente contencioso) eu provavelmente faria 2 seguido por 3 ou 4. ou seja, definitivamente haveria algumas pessoas com as quais eu não falaria pessoalmente sobre o assunto, mas no Por outro lado, a maioria das pessoas-chave teria a chance de contribuir para a tomada de decisões.

Para mim, a bandeira vermelha real estaria por perto se você sentir que a decisão errada foi tomada (errado = = prejudica a empresa e não apenas sua ferramenta favorita não escolhida). Como a gerência reage quando você levanta este problema:

• A boa administração ouvirá seu argumento, obrigado sinceramente pelo feedback e reconsiderará sua posição no caso de você ter levantado novos insights . Eles ainda podem não concordar com você e podem se ater à sua decisão, mas eles perceberão que você levantou a questão com eles e faz a gentileza 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 pontos, pode incluí-lo em sua lista de "pessoas inteligentes para perguntar".
• O mau gerenciamento se tornará defensivo, dizendo que "a decisão é tomada" e outras táticas desse tipo para evitar enfrentar o fato de que eles podem ter tomado uma decisão errada. Eles podem ver você como um "encrenqueiro". A empresa sofre, assim como sua fé na administração. Esta é uma verdadeira bandeira vermelha! Saia enquanto puder!

Se você estiver usando maven ou algo similar, não importa qual IDE você está usando. Pode haver casos em que um está vinculado a um IDE específico, como o eclipse, se houver plug-ins em que você confia.

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

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

No IDE frente ao editor ... para quase todas as linguagens, eu strongmente prefiro um IDE (IntelliJ) porque há muito mais que você pode fazer do que um editor. Há algumas coisas que eu reverti para ST2 ou Emacs, mas para codificação do dia-a-dia, apesar do quanto eu gosto de ambos os ST2 / Emacs, o IDE quase sempre ganha.

Cada equipe em que já 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 importante é deixar que os bons codificadores façam o que precisam e usem 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, testes de unidade, algoritmos, etc.

Ter o mesmo IDE do 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 está configurada. Nada disso importa quando se fala de questões reais de código.

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

Em nossa loja de Ruby , há uma strong recomendação para usar o IDE que a maioria da equipe gosta (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, se assim o desejarem. Se vemos alguém lutando para navegar em seu projeto ou editar texto em seu FooEdit personalizado, o RubyMine é para eles.

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

Ser forçado a padronizar uma IDE parece uma ideia terrível.

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

Esta é uma enorme bandeira vermelha. Toda empresa tem algumas ideias idiotas, mas se outras bandeiras vermelhas continuarem, saia.

É fácil para a motivação por trás de algumas decisões serem perdidas - especialmente com equipes 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 sobre a sua empresa.

Eu apenas tomaria o comando para migrar para o Eclipse para significar que você deve ter a configuração do Eclipse caso seja necessário, mas continue seu trabalho no editor favorito. (Você pode ter que ir para o Eclipse gradualmente se sua empresa começar a implementar ferramentas legais no Eclipse.)

Uma startup geralmente está tentando se manter ágil por tempo suficiente para descobrir um modelo de negócio sustentável. Uma vez que descobre a parte do dinheiro, a gerência se move para expandir o negócio. Geralmente, quando todos os primeiros funcionários de tecnologia começam a sair, os processos de engenharia são reforçados.

Como você sabe, você não sabe o que o código realmente fará até você executá-lo. Turing provou isso nos primórdios da computação. Isso significa que não existe uma medida significativa de produtividade quando se trata de escrever um 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 gerencial típica tenta controlar os programadores para tornar essas coisas legíveis para eles (em vez de fazer seus trabalhos reais: 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 eles quebram todas as regras nos livros didáticos de gerenciamento de negócios. Eles parecem estar fazendo tudo certo. Bugs são consertados (eventualmente). Recursos são adicionados. Incêndios são apagados.

O que é uma grande bandeira vermelha é se eles estão tentando escalar as coisas sem ter descoberto como ganhar dinheiro. Nesse ponto, você deve se perguntar quanto de suas opções e subsídios não investidos valem a pena.

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

Desde que eu tentei várias ferramentas eu sempre tive em algum momento que sentindo "meu Deus, este editor está me irritando com < inserir algum erro / diferença da ferramenta preferida >". Então, será uma desvantagem moral também.

Mas é claro que também existem profissionais para que uma equipe inteira use as mesmas ferramentas. Compartilhando configs, 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 bit não seria necessário se todos usassem seu software preferido. ;)

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

Isso significa ter o Eclipse instalado e configurado para seus projetos e estar em dia com ele, para que você esteja igualmente confortável usando-o se, digamos, programar em pares. Ninguém vai (ou pelo menos deve) se importar com o editor que você usou para digitar um trecho de código que você tenha cometido, desde que manter sua configuração paralela não ocupe uma quantidade indevida de 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 será necessário usar os editores uns dos outros de qualquer maneira. Você pode simplesmente empurrar um branch e fazer com que outro desenvolvedor o puxe para que ele funcione se ele realmente não conseguir descobrir o 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 não entende realmente como você opera.

Se você pensar sobre isso do ponto de vista da gerência, a razão pela qual eles podem estar fazendo isso é para a conformidade legal. A empresa é responsável por garantir que todas as ferramentas utilizadas estejam sendo usadas legalmente e também não sobrecarreguem o produto que está sendo desenvolvido. (Alguns editores são gratuitos para uso pessoal, mas não gratuitos para quaisquer outros fins, etc.) Para auditar todas as ferramentas que cada desenvolvedor pode querer usar pode ser caro. Eu vi isso em projetos em que as linhas de tempo estão apertadas, 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 segurança mais alta, 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 das razões pelas quais eles têm que recomendar 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 estivessem felizes e produtivos usando o que quisessem, há poucas razões para impor uma mudança em algo tão profundamente envolvido no processo criativo.

O Eclipse é muito mais do 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 exigido pela corporação queira.

Uma última coisa - aplicar o processo nesse nível pode indicar que a empresa pretende expandir a equipe de desenvolvimento e deseja ter um pouco de estrutura para que os novos colegas de equipe possam se tornar produtivos mais rapidamente. Se você acha que o Rails (ou Django) é uma estrutura "opinativa", perceberá que ter estrutura ajuda a entender novos aplicativos mais facilmente.

O sinalizador vermelho não é tanto que um único IDE / editor está sendo forçado em todos os desenvolvedores, mas que essa decisão, e especialmente a decisão sobre qual IDE / editor deve ser usado, não foi feita por todos os desenvolvedores, e talvez nenhum deles!?!

Certamente, seria melhor para os desenvolvedores chegarem a um consenso, especialmente porque eles são obviamente 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.

Conseguir que 12 desenvolvedores façam alguns votos seria fácil. Certamente houve tempo suficiente para fazer isso! A conclusão teria sido dolorosa para alguns de qualquer forma e pode até ter acabado sendo Eclipse no final, mas rotular a exigência como uma "bandeira vermelha" nesse caso seria muito mais discutível.