Cuidado com o papo de 'a ferramenta certa para o trabalho'

Publicado em Novembro 18, 2015

Quando comecei minha carreira eu não entendia bem o conceito de me fixar a uma única linguagem/tecnologia. Sempre me pareceu errado fazer isso porque você precisa “usar a ferramenta certa para o trabalho” e " se não se parece com um prego, não use um martelo “, mas hoje acho que, como sempre, a realidade é um pouco mais complexa.

Eu ainda acredito que, como desenvolvedor, sou mais capaz e produtivo aprendendo cada vez mais linguagens/plataformas/ferramentas/frameworks/etc. Com essa mentalidade tenho a capacidade para sugerir novas soluções, evitar caminhos ruins e manter minha mente afiada, me tornando assim um profissional melhor.

No entanto, quando se trata de ambientes corporativos, especialmente empresas grandes, faz mais sentido focar em algumas tecnologias específicas (especialmente se você não entrou na equipe de microsserviços … mais sobre isso em outro post). E as razões para isso são muitas:

Contratações mais simples

Contratar é uma atividade que consome muito tempo e dinheiro. Você provavelmente não vai contratar o primeiro entrevistado, e você não pode esperar que pessoas entrem em sua equipe prontas para enfrentar os maiores problemas. Ter uma stack reduzida ajuda a colocar as pessoas para dentro e diminui o tempo delas de compreensão do ambiente. Em vez de listar muitas tecnologias e práticas para uma vaga, você pode procurar alguém que tenha um conhecimento específico, tornando sua busca mais específica e direta.

A ideia deve ser “Precisamos que você saiba disso e um pouco daquilo”, em vez de “Precisamos que você saiba tudo sobre tudo”.

Otimização de manutenção

Não é novidade para ninguém da área que manutenção é onde passamos a maior parte do tempo como desenvolvedores de software. Ter seus sistemas funcionando com tecnologias similares torna mais fácil desenvolver habilidades que serão úteis em todas as funcionalidades.

A ideia é: “Se você aprender essa tecnologia no sistema X, será mais simples embarcar no projeto com o sistema Y”.

Padronização

Algumas ferramentas têm todo um ecossistema dedicado a elas (como sonar -> Java ou Code Climate -> rubi) . Ao padronizar as tecnologias, você pode aproveitar os benefícios das métricas para um melhor planejamento e fazer uso completo dos ecossistemas dedicados. Até mesmo a rotação de membros de equipe se torna menos dolorosa se, ao migrar de equipe, as pessoas saibam que no novo ambiente suas habilidades já são valiosas.

Pense em “Podemos padronizar nosso pipeline se usarmos X para backend Y para frontend”.

Mitigar ainda mais os silos de conhecimento

Um pouco de contorcionismo argumentativo, eu sei, mas a padronização também evita um pouco o famoso “João é o unico que sabe como esse sistema funciona”.

Idealmente seria “qualquer programador consegue trabalhar em qualquer sistema de empresa”.

The list of benefits go on, but you got the idea.

A lista de benefícios continua, mas você entendeu a ideia.

Só ressaltando, ainda acho que desenvolvedores precisam ter fome de conhecimento, mas devemos ter cuidado para não construir um ambiente no qual não sabemos em qual tecnologia os sistemas estão sendo escritos, e, pior, com pessoas entrando e saindo da empresa ao longo do tempo.

É importante pensar no longo prazo, focando no “se eu saisse da empresa amanhã, seria fácil para eles continuarem o trabalho que fiz?”.

Abraço!

origem da imagem do post: CodingHorror